Methods and systems for computer aided event and venue setup and modeling and interactive maps

ABSTRACT

Described are systems and methods for designing certain aspects of an event venue and for communicating information regarding the event and the event venue to others. Certain embodiments provide a dynamic seat map via which an operator can assign certain characteristics to specific seats and/or seating sections. Certain embodiments generate interactive maps for users, via which information from a plurality of sources may be integrated and visually displayed. The user may specify certain criteria, and the interactive map may identify to the user seats and/or sections that match such criteria. Certain embodiments provide an interactive seat map via which users can select seats and share information.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority from U.S. Patent Application No.61/355,000, filed Jun. 15, 2010, the content of which is incorporatedherein by reference in its entirety.

COPYRIGHT RIGHTS

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the reproduction by any one of the patent document or thepatent disclosure, as it appears in the patent and trademark officepatent file or records, but otherwise reserves all copyright rightswhatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is related to computer aided design and toelectronic maps, and in particular, to computer aided event and venuesetup and to interactive maps.

2. Description of the Related Art

Event ticketing typically involves pricing and selling tickets. Certainconventional techniques statically price event tickets. That is, once aprice is set for a ticket or class of tickets with respect to an initialsale of those tickets, the price does not change. Further, usingconventional techniques, ticket pricing is often based on insufficientinformation, resulting in ticket prices that are too high or too lowgiven the actual demand for such tickets.

In addition, ever greater numbers of event ticket are sold online,rather than via telephone or brick-and-mortar outlets. However,conventional seating maps for venues presented in conjunction with suchonline sales tend to be static, and fail to adequately provide relevantreal time dynamic data. Further, conventional seating maps fail toprovide adequate interfaces for enabling users to quickly locatesuitable seats.

SUMMARY OF THE INVENTION

The following presents a simplified summary of one or more aspects inorder to provide a basic understanding of such aspects. This summary isnot an extensive overview of all contemplated aspects, and is intendedto neither identify key or critical elements of all aspects nordelineate the scope of any or all aspects. Its sole purpose is topresent some concepts of one or more aspects in a simplified form as aprelude to the more detailed description that is presented later.

Described herein are methods and systems for creating ticketed eventsand executing ticket sales (e.g., utilizing interactive ticket maps). Inparticular, certain methods and systems described herein are configuredto create ticketed events, set ticket prices, and execute ticket salesvia dynamic interactive user interfaces.

An example ticket system, configured to set ticket prices and/or to selltickets, is networked to systems of box offices, promoters, artistmanagers, venue set-up personnel, social network systems, and/orpotential ticket purchasers.

Certain embodiments receive and utilize information, such as eventticket sale information, timing of event, occurrence of competingattractions, and/or other information to set initial pricing and/or toadjust previously set pricing of event tickets. Certain embodimentsprovide interactive seating maps configured to facilitate userunderstanding of the available seats, prices, available discounts,seating packages, etc., by providing a comprehensive graphical view ofwhat may be a complex set of prices and promotions.

Discussed herein is a system for providing an interactive seat map,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising: accessing a seatmap for a venue, the seat map including a definition of a plurality ofsections and seats within the plurality of sections; optionallyaccessing pricing information associated with the plurality of venuesections and/or venue seats for a first event; providing the map to auser terminal for display as an interactive seat map including sectionsand/or individual seats in association with one or more of thefollowing: an interface via which the user can specify a price rangewith respect to seat tickets; an interface via which the user canspecify at least a first offer, wherein the first offer provides atleast one of the following: a reduced price with respect to at least oneseat ticket; a reduced price with respect to an ancillary product orservice in association with at least one ticket purchase; an entitlementto purchase seat tickets for a certain category of seats if acorresponding offer code is supplied; receiving, via a data interface,receive relationship information with respect to the user, wherein therelationship information includes identifications of one or more friendsof the user; wherein, in at least partly in response to a user specifiedprice range and/or a user specified offer, the interactive seat mapemphasizes sections and/or seats corresponding to the user specifiedprice range and/or the user specified offer; accessing seat informationwith respect to one or more friends of the user; causing, at least inpart, the interactive seat map to indicate sections and/or seats whereat least a portion of the user's friends have tickets for; and receivingand processing a ticket purchase request for at least one seat selectedby the user via the interactive seat map.

Discussed herein is a method comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of sections and seats within the plurality ofsections; accessing pricing information associated with the plurality ofvenue sections and/or venue seats for a first event; providing the mapto a user terminal for display as an interactive seat map includingsections and/or individual seats in association with: an interface viawhich a user can specify a price range with respect to seat tickets; aninterface via which the user can specify at least a first offer, whereinthe first offer provides at least one of the following: a reduced pricewith respect to at least one seat ticket; a reduced price with respectto an ancillary product or service in association with at least oneticket purchase; an entitlement to purchase seat tickets for a certaincategory of seats if a corresponding offer code is supplied; receiving,via a data interface, receive relationship information with respect tothe user, wherein the relationship information includes identificationsof one or more friends of the user; wherein, in at least partly inresponse to a user specified price range and/or a user specified offer,the interactive seat map emphasizes sections and/or seats correspondingto the user specified price range and/or the user specified offer;accessing seat information with respect to one or more friends of theuser; causing, at least in part, the interactive seat map to indicatesections and/or seats where at least a portion of the user's friendshave tickets for; and receiving and processing a ticket purchase requestfor at least one seat selected by the user via the interactive seat map.

Discussed herein is a system for providing an interactive seat map,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising: accessing a seatmap for a venue, the seat map including a definition of a plurality ofsections and seats within the plurality of sections; accessing pricinginformation associated with the plurality of venue sections and/or venueseats for a first event; transmitting the map for display as aninteractive seat map on a user terminal in association with: aninterface via which a user can specify a price range with respect toseat tickets; receiving, via a data interface, relationship informationwith respect to the user, wherein the relationship information includesidentifications of one or more friends of the user; accessing seatinformation with respect to one or more friends of the user; andwherein, in response to a user-specified price range, the interactiveseat map emphasizes sections and/or seats corresponding to the userspecified price range, and wherein the interactive map indicates wherethe one or more of the user's friends are sitting; receiving andprocessing a ticket purchase request for at least one seat selected bythe user via the interactive seat map.

Discussed herein is a method comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of sections and seats within the plurality ofsections; accessing pricing information associated with the plurality ofvenue sections and/or venue seats for a first event; transmitting themap for display as an interactive seat map on a user terminal inassociation with: an interface via which the user can specify a pricerange with respect to seat tickets; receiving, via a data interface,relationship information with respect to the user, wherein therelationship information includes identifications of one or more friendsof the user; accessing seat information with respect to one or morefriends of the user; and wherein, in response to a user specified pricerange, the interactive seat map emphasizes sections and/or seatscorresponding to the user specified price range, and wherein theinteractive map indicates where the one or more of the user's friendsare sitting; receiving and processing a ticket purchase request for atleast one seat selected by the user via the interactive seat map.

Discussed herein is a system for providing a venue seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing hardware toperform operations comprising: accessing a seat map for a venue, theseat map including a definition of a plurality of seats; receiving, viaa data interface, relationship information with respect to a user,wherein the relationship information includes identifications of one ormore friends of the user; accessing seat information with respect to oneor more friends of the user; and causing the seat map to indicate wherethe one or more of the user's friends are sitting.

Discussed herein is a method comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of seats; receiving, via a data interface,relationship information with respect to a user, wherein therelationship information includes identifications of one or more friendsof the user; accessing seat information with respect to one or morefriends of the user; and causing the seat map to indicate where the oneor more of the user's friends are sitting.

Discussed herein is a system for providing an interactive seat map,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising: accessing a seatmap for a venue, the seat map including a definition of a plurality ofsections and seats within the plurality of sections; accessing pricinginformation associated with the plurality of venue sections and/or venueseats for a first event; accessing status information regarding aplurality of venue seats, the status information indicating seatavailability; transmitting the map for display as an interactive seatmap on a user terminal, wherein the interactive map indicates seatavailability; providing a user interface via which: a user may select aseat for which a ticket is already held by a ticket holder that hadpreviously acquired the ticket, and submit an offer, including a userspecified price, to purchase the ticket for the selected seat from theticket holder; if the user submits an offer to the ticket holder,transmitting the offer to the ticket holder, and processing anacceptance or refusal of the offer from the ticket holder.

Discussed herein is a method, comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of sections and seats within the plurality ofsections; accessing status information regarding a plurality of venueseats, the status information indicating seat availability; transmittingthe map for display as an interactive seat map on a user terminalwherein the interactive map indicates seat availability; providing auser interface via which: a user may select a seat for which a ticket isalready held by a ticket holder that had previously acquired the ticket,and submit an offer, including a user specified price, to purchase theticket for the selected seat from the ticket holder; if the user submitsan offer to the ticket holder, transmitting the offer to the ticketholder, and processing an acceptance or refusal of the offer from theticket holder.

Discussed herein is a system for providing a seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing system toperform operations comprising: accessing a seat map for a venue, theseat map including a definition of a plurality of seats; accessingpurchase process information, wherein the purchase process informationindicates: a first ticket for a first seat is to be offered for sale viaa first purchase process type, and a second ticket for a second seat isto be offered for sale via a second purchase process type different thanthe first purchase process type; accessing status information regardinga plurality of venue seats, the status information indicating seatavailability; transmitting the seat map for display on a user terminal,wherein the seat map indicates seat availability, and where the seat mapvisually indicates that: the first ticket for the first seat isavailable for purchase via the first purchase process type, and thesecond ticket for the second seat is available for purchase via thesecond purchase process type; providing a user interface enabling auser: to select the first seat via the seat map and to initiate apurchase transaction for the first ticket using the first purchaseprocess type, and/or to elect the second seat via the seat map and toinitiate a purchase transaction for the second ticket using the secondpurchase process type.

Discussed herein is a method, comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of seats; accessing purchase processinformation, wherein the purchase process information indicates: a firstticket for a first seat is to be offered for sale via a first purchaseprocess type, and a second ticket for a second seat is to be offered forsale via a second purchase process type different than the firstpurchase process type; accessing status information regarding aplurality of venue seats, the status information indicating seatavailability; transmitting the seat map for display on a user terminal,wherein the seat map indicates seat availability, and where the seat mapvisually indicates that: the first ticket for the first seat isavailable for purchase via the first purchase process type, and thesecond ticket for the second seat is available for purchase via thesecond purchase process type; providing a user interface enabling auser: to select the first seat via the seat map and to initiate apurchase transaction for the first ticket using the first purchaseprocess type, and/or to elect the second seat via the seat map and toinitiate a purchase transaction for the second ticket using the secondpurchase process type.

Discussed herein is a system for providing a seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing hardware toperform operations comprising: accessing a seat map for a venue, theseat map including a definition of a plurality of seats; transmittingthe seat map for display on a terminal of a first user, wherein the seatmap indicates seat availability, and providing a user interface enablingthe first user: to select the first seat via the seat map and to submita first offer to purchase a corresponding first ticket for the firstseat; identify a second user; condition the offer to purchase the firstticket for the first seat on an acceptance of a second offer from thesecond user to purchase a second ticket for a second seat; determiningif the second offer to purchase the second ticket for the second seat isacceptable; determining if the first offer to purchase the first ticketfor the first seat is acceptable, at least partly in response todetermining that the first offer to purchase the first ticket for thefirst seat the second offer to purchase the second ticket for the secondseat are acceptable, enabling the purchase of the first ticket to becompleted.

Discussed herein is a method, comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of seats; transmitting the seat map fordisplay on a terminal of a first user, wherein the seat map indicatesseat availability, and providing a user interface enabling the firstuser: to select the first seat via the seat map and to submit a firstoffer to purchase a corresponding first ticket for the first seat;identify a second user; condition the offer to purchase the first ticketfor the first seat on an acceptance of a second offer by the second userto purchase a second ticket for a second seat; determining if the secondoffer to purchase the second ticket for the second seat is acceptable;determining if the first offer to purchase the first ticket for thefirst seat is acceptable, at least partly in response to determiningthat the first offer to purchase the first ticket for the first seat thesecond offer to purchase the second ticket for the second seat areacceptable, enabling the purchase of the first ticket to be completed.

Discussed herein is a system for providing a seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing hardware toperform operations comprising: determining if user activity by aplurality of users is interfering with providing, to a plurality of userterminals, substantially real-time updates to an interactive seat map,wherein the interactive seat map enables a given user to select aspecific seat via the interactive seat map and to purchase a seat ticketfor the user selected seat; at least partly in response to determiningthat user activity is interfering with providing, to the plurality ofuser terminals, substantially real-time updates to the interactive seatmap: preventing at least a portion of the plurality of users from usingthe interactive seat map to purchase user selected seats; and enablingone or more users to purchase seat tickets via a first user interfacewherein the user cannot select specific seat to purchase tickets for.

Discussed herein is a method, comprising some or all of the followingacts: determining if user activity by a plurality of users isinterfering with providing, to a plurality of user terminals,substantially real-time updates to an interactive seat map, wherein theinteractive seat map enables a given user to select a specific seat viathe interactive seat map and to purchase a seat ticket for the userselected seat; at least partly in response to determining that useractivity is interfering with providing, to the plurality of userterminals, substantially real-time updates to the interactive seat map:preventing at least a portion of the plurality of users from using theinteractive seat map to purchase user selected seats; and enabling oneor more users to purchase seat tickets via a first user interfacewherein the user cannot select specific seat to purchase tickets for.

Discussed herein is a method for providing an interactive venue map,comprising some or all of the following acts: detecting that a user isat a first venue for a first event; providing an interactive venue mapof the first venue for display on a mobile user terminal; identifyingone or more friends of the user attending the first event at the firstvenue; identifying seats locations of the one or more friends of theuser; including an indication on the interactive venue map as to theseating locations of the one or more friends within the first venue forthe first event.

Discussed herein is a system for providing a seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing hardware toperform operations comprising: detecting that a user is at a first venuefor a first event; providing an interactive venue map of the first venuefor display on a mobile user terminal; identifying one or more friendsof the user attending the first event at the first venue; identifyingseats locations of the one or more friends of the user; including anindication on the interactive venue map as to the seating locations ofthe one or more friends within the first venue for the first event.

Discussed herein is a method for providing an interactive venue map,comprising some or all of the following acts: detecting that a user isat a first venue for a first event; providing an interactive venue mapof the first venue for display on a mobile user terminal; receivingcurrent location information from the mobile user terminal while themobile user terminal is at the first venue; estimating line durationtimes for a plurality of destinations of a first destination type; andtransmitting to the mobile user terminal information relating to anestimated line duration time for at least one of the plurality ofdestinations of the first destination type.

Discussed herein is a system for providing a seat map, comprising:computing hardware; a non-transitory medium storing instructions thatwhen executed by the computing hardware, cause the computing hardware toperform operations comprising: detecting that a user is at a first venuefor a first event; providing an interactive venue map of the first venuefor display on a mobile user terminal; receiving current locationinformation from the mobile user terminal while the mobile user terminalis at the first venue; estimating line duration times for a plurality ofdestinations of a first destination type; and transmitting to the mobileuser terminal information relating to an estimated line duration timefor at least one of the plurality of destinations of the firstdestination type.

Discussed herein is a system for controlling an image display on aremote device, comprising: computing hardware; a non-transitory mediumstoring instructions that when executed by the computing hardware, causethe computing hardware to perform operations comprising: detecting thepresence of the remote device at an event venue, the event venueincluding a plurality of seats; identifying a first user associated withthe remote device; determining what is being displayed in the remotedevice display associated with the first user; accessing relationshipinformation for the first user, the relationship information identifyingat least a second user with whom the first user has a relationship;identifying a seating location in the event venue that is associatedwith the second user; at least partly in response to determining thatthe seating location associated with the second user is being displayedin the remote device display associated with the first user, causingcomputer generated data to be displayed in association with thedisplayed seating location, the computer generated data including anidentifier of the second user and/or an indication that the first userhas a relationship with second user.

Discussed herein is a method, comprising some or all of the followingacts: detecting the presence of the remote device at an event venue, theevent venue including a plurality of seats; identifying a first userassociated with the remote device; determining what is being displayedin the remote device display associated with the first user; accessingrelationship information for the first user, the relationshipinformation identifying at least a second user with whom the first userhas a relationship; identifying a seating location in the event venuethat is associated with the second user; at least partly in response todetermining that the seating location associated with the second user isbeing displayed in the remote device display associated with the firstuser, causing computer generated data to be displayed in associationwith the displayed seating location, the computer generated dataincluding an identifier of the second user and/or an indication that thefirst user has a relationship with second user.

Discussed herein is a system for configuring a ticketed event,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising: accessing a seatmap for a venue, the seat map including a definition of a plurality ofsections and seats within the plurality of sections; providing the venueseat map for display on a user terminal; accessing from memory andproviding for display in association with the venue seat map an eventname for a ticketed event that is being setup using the venue seat map;accessing from memory and providing for display in association with thevenue seat map a name associated with the venue; accessing from memoryand providing for display in association with the venue seat map a dateof the event this is being setup using the venue map; accessing frommemory and providing seat status information, the seat stationinformation indicating how many seats are in the venue for which ticketsare to be offered for sale; accessing monetary value information (e.g.,the ticket face value and/or other ticket related fees (e.g., servicefees, facility fees, handling fees, shipping fees, etc.)) for ticketscorresponding to the seats for which tickets are to be offered for sale;calculating a potential revenue for the event based at least in part onthe monetary value information and how many seats are in the venue forwhich tickets are to be offered for sale; providing the calculatedpotential event revenue for display on the user terminal; accessing frommemory and providing for display a listing of a plurality of pricelevels, wherein a given price level is associated with a subset of theseats for which tickets are to be offered for sale; providing fordisplay a monetary value of tickets associated with seats in the givenprice level; providing for display how many seats are associated withthe given price level; calculating and providing for display a revenuepotential for the given price level; providing for display on the userterminal a user interface via which a user can alter: a seat countassociated with the given price level; and the monetary value of ticketsassociated with seats in the given price level; calculating andproviding for display a new revenue potential for the given price levelbased at least in part on a user alteration of the monetary value oftickets associated with seats in the given price level and/or a useralteration of the seat count for the given price level.

Discussed herein is a method, comprising some or all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of sections and seats within the plurality ofsections; providing the venue seat map for display on a user terminal;accessing from memory and providing for display in association with thevenue seat map an event name for a ticketed event that is being setupusing the venue seat map; accessing from memory and providing fordisplay in association with the venue seat map a name associated withthe venue; accessing from memory and providing for display inassociation with the venue seat map a date of the event this is beingsetup using the venue map; accessing from memory and providing seatstatus information, the seat station information indicating how manyseats are in the venue for which tickets are to be offered for sale;accessing monetary value information (e.g., the ticket face value and/orother ticket related fees (e.g., service fees, facility fees, handlingfees, shipping fees, etc.)) for tickets corresponding to the seats forwhich tickets are to be offered for sale; calculating a potentialrevenue for the event based at least in part on the monetary valueinformation and how many seats are in the venue for which tickets are tobe offered for sale; providing the calculated potential event revenuefor display on the user terminal; accessing from memory and providingfor display a listing of a plurality of price levels, wherein a givenprice level is associated with a subset of the seats for which ticketsare to be offered for sale; providing for display a monetary value oftickets associated with seats in the given price level; providing fordisplay how many seats are associated with the given price level;calculating and providing for display a revenue potential for the givenprice level; providing for display on the user terminal a user interfacevia which a user can alter: a seat count associated with the given pricelevel; and the monetary value of tickets associated with seats in thegiven price level; calculating and providing for display a new revenuepotential for the given price level based at least in part on a useralteration of the monetary value of tickets associated with seats in thegiven price level and/or a user alteration of the seat count for thegiven price level.

Discussed herein is a system for configuring a ticketed event,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising some of all of thefollowing acts: accessing a seat map for a venue, the seat map includinga definition of a plurality of sections and seats within the pluralityof sections; providing the venue seat map for display on a userterminal; providing for display an identifier associated with an eventbeing defined using the venue map; providing a user interface fordisplay via which a user can specify ticket prices for seats selectedvia the seat map; calculating a potential revenue for the event based atleast in part on the specified tickets prices and how many seats are inthe venue for which tickets are to be offered for sale; providing thecalculated potential event revenue for display on the user terminal;accessing from memory and providing for display a listing of a pluralityof price levels, wherein a given price level is associated with a subsetof the seats for which tickets are to be offered for sale; providing fordisplay a ticket price associated with seats in a first price level;providing for display how many seats are associated with the first pricelevel; calculating and providing for display a revenue potential for thefirst price level; providing for display on the user terminal a userinterface via which a user can alter a monetary value (e.g., the ticketface value and/or other ticket related fees (e.g., service fees,facility fees, handling fees, shipping fees, etc.)) of ticketsassociated with seats in a second price level after one or more ticketsto the event have been sold; calculating and providing for display a newrevenue potential for the given price level based at least in part on auser alteration of the monetary value of tickets associated with seatsin the second price level.

Discussed herein is a method comprising: accessing from memory a seatmap for a venue, the seat map including a definition of a plurality ofsections and seats within the plurality of sections; providing the venueseat map for display on a user terminal; providing for display anidentifier associated with an event being defined using the venue map;providing a user interface for display via which a user can specifyticket prices for seats selected via the seat map; calculating, using acomputing device, a potential revenue for the event based at least inpart on the specified tickets prices and how many seats are in the venuefor which tickets are to be offered for sale; providing the calculatedpotential event revenue for display on the user terminal; accessing frommemory and providing for display a listing of a plurality of pricelevels, wherein a given price level is associated with a subset of theseats for which tickets are to be offered for sale; providing fordisplay a ticket price associated with seats in a first price level;providing for display how many seats are associated with the first pricelevel; calculating and providing for display a revenue potential for thefirst price level; providing for display on the user terminal a userinterface via which a user can alter a monetary value of ticketsassociated with seats in a second price level after one or more ticketsto the event have been sold; calculating and providing for display a newrevenue potential for the given price level based at least in part on auser alteration of the monetary value of tickets associated with seatsin the second price level.

Discussed herein is a method comprising: accessing, via a computersystem, a user interface including a seat map for a first venue for afirst ticketed event, wherein the first venue includes a plurality ofseats; defining a first plurality of price levels for the first ticketedevent; selecting, via the seat map, one or more seats; associating theselected seats with a given price level in the first plurality of pricelevels; assigning monetary values to respective price levels in thefirst plurality of price levels; causing the computer system tocalculate a first potential revenue for the first ticketed event,wherein the first potential revenue is based at least in part on themonetary values assigned to the respective price levels and how manyseats are associated with respective price levels; changing a first ofthe monetary values assigned to a first of the price levels to a secondmonetary value; and causing the computer system to calculate a secondpotential revenue for the first ticketed event, wherein the secondpotential revenue is based at least in part on the monetary valuesassigned to the respective price levels, including the second monetaryvalue, and how many seats are associated with respective price levels.

Discussed herein is a method comprising some of all of the followingacts: accessing a seat map for a venue, the seat map including adefinition of a plurality of sections and seats within the plurality ofsections; providing the venue seat map for display on a user terminal;providing for display an identifier associated with an event beingdefined using the venue map; providing a user interface for display viawhich a user can specify ticket prices for seats selected via the seatmap; calculating a potential revenue for the event based at least inpart on the specified tickets prices and how many seats are in the venuefor which tickets are to be offered for sale; providing the calculatedpotential event revenue for display on the user terminal; accessing frommemory and providing for display a listing of a plurality of pricelevels, wherein a given price level is associated with a subset of theseats for which tickets are to be offered for sale; providing fordisplay a ticket price associated with seats in a first price level;providing for display how many seats are associated with the first pricelevel; calculating and providing for display a revenue potential for thefirst price level; providing for display on the user terminal a userinterface via which a user can alter a monetary value (e.g., the ticketface value and/or other ticket related fees (e.g., service fees,facility fees, handling fees, shipping fees, etc.)) of ticketsassociated with seats in a second price level after one or more ticketsto the event have been sold; calculating and providing for display a newrevenue potential for the given price level based at least in part on auser alteration of the monetary value of tickets associated with seatsin the second price level.

Discussed herein is a system for configuring a ticketed event,comprising: computing hardware; a non-transitory medium storinginstructions that when executed by the computing hardware, cause thecomputing hardware to perform operations comprising: providing a userinterface via which a user can assign a first user an advisor role, asecond user an decision maker role, and a third user an implementerroad, wherein the advisor is entitled to provisionally change at leastone ticket pricing setting and evaluate a corresponding impact on apotential revenue and provide a corresponding event setup proposal to bepresented to the decision maker, but the advisor is not entitled toimplement the change in the at least one ticket pricing setting withrespect to an on-sale event; the decision maker is entitled review theadvisor proposal and approve or disapprove the advisor proposal via thesystem; the implementer is entitled to implement, via the system, theadvisor proposal if approved by the decision maker.

Discussed herein is a method, comprising some or all of the followingacts: providing a user interface via which a user can assign a firstuser an advisor role, a second user an decision maker role, and a thirduser an implementer road, wherein the advisor is entitled toprovisionally change at least one ticket pricing setting and evaluate acorresponding impact on a potential revenue and provide a correspondingevent setup proposal to be presented to the decision maker, but theadvisor is not entitled to implement the change in the at least oneticket pricing setting with respect to an on-sale event; the decisionmaker is entitled review the advisor proposal and approve or disapprovethe advisor proposal via the system; the implementer is entitled toimplement, via the system, the advisor proposal if approved by thedecision maker.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed aspects will hereinafter be described in conjunction withthe appended drawings, provided to illustrate and not to limit thedisclosed aspects, wherein like designations denote the elements.

FIG. 1A illustrates an example computer-based architecture.

FIG. 1B illustrates an example process.

FIG. 2 illustrates an example user interface that enables a user todesign an event and to view an event design.

FIG. 3 illustrates an example user interface that visually provides heldseat information.

FIG. 4 illustrates an example user interface via which a user can varyticket parameters and view projected results.

FIG. 5 illustrates an example user interface providing an event summaryand a color coded seating chart providing seating information andstatus.

FIG. 6 illustrates an example user interface providing an event summaryfor multiple events and a color coded seating chart providing seatinginformation and pricing information.

FIG. 7 illustrates an example user interface of an event modeling tool.

FIG. 8 illustrates an example flex execution tool user interface.

FIG. 9 illustrates an example on-sale distiller tool user interface.

FIG. 10 illustrates an example price break report.

FIG. 11 illustrates an example real-time sales map.

FIG. 12 illustrates another example user interface, providing, via agraph, substantially real-time sales rate information.

FIG. 13 illustrates an example price break report.

FIG. 14 illustrates an example report specification user interface.

FIGS. 15-19 illustrate example reporting user interfaces.

FIGS. 20, 21A-21Z, and 23-26 illustrate example interactive seat maps.

FIG. 22 illustrates an example pricing matrix.

FIG. 27 illustrates an example augmented reality user interface.

FIG. 28 illustrates an example ticketing process.

FIGS. 29A-H illustrate additional event creation user interfaces.

FIG. 30 illustrates an example event setup process.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Conventional approaches to ticket pricing suffer from significantdeficiencies. Conventional pricing techniques often set ticket pricesfor certain tickets at too low a price. That is, ticket purchasers wouldhave been willing to pay more than the face price for the ticket. Thisunder-pricing of the ticket therefore results in a loss of potentialrevenues to the ticket seller, the performer/artist, and the promoter.Often, conventional ticket pricing overprices tickets. That is, theticket price is set higher than sufficient numbers ticket purchasers arewilling to pay to consume the available inventory of tickets or anadequate portion of the available inventory of tickets. This overpricingof tickets therefore results in a loss of potential revenues to theticket seller.

Further, conventional seating maps for venues presented in conjunctionwith ticket sales tend to be static, and fail to provide relevant realtime dynamic data. In addition, conventional seating maps fail tocoherently integrate and display relevant seating, ticketing, and eventinformation.

Certain example embodiments described herein may address some or all ofthe deficiencies of the conventional techniques discussed above. Certainembodiments may be implemented via hardware, software stored on media,or a combination of hardware and software. For example, certainembodiments may include software/program instructions stored ontangible, non-transitory computer-readable medium (e.g., magneticmemory/discs, optical memory/discs, RAM, ROM, FLASH memory, othersemiconductor memory, etc.), accessible by one or more computing devicesconfigured to execute the software (e.g., servers or other computingdevice including one or more processors, wired and/or wireless networkinterfaces (e.g., cellular, WiFi, Bluetooth, T1, DSL, cable, optical, orother interface(s) which may be coupled to the Internet), contentdatabases, customer account databases, etc.). Data stores (e.g.,databases) may be used to store some or all of the information discussedherein (e.g., seating maps, pricing information, seat status, purchaseinformation, ticket information, etc.).

By way of example, a given computing device may optionally include userinterface devices, such as some or all of the following: one or moredisplays, keyboards, touch screens, speakers, microphones, mice, trackballs, touch pads, printers, etc. The computing device may optionallyinclude a media read/write device, such as a CD, DVD, Blu-ray, tape,magnetic disc, semiconductor memory, or other optical, magnetic, and/orsolid state media device. A computing device, such as a user terminal,may be in the form of a general purpose computer, a personal computer, alaptop, a tablet computer, a mobile or stationary telephone, aninteractive television, a set top box coupled to a display, etc.

Described herein are methods and systems for creating ticketed eventsand executing ticket sales. In particular, certain methods and systemsdescribed herein are configured to create ticketed events, set ticketprices, and execute ticket sales via dynamic interactive userinterfaces.

An example ticket system, configured to set ticket prices and/or to selltickets, is networked (e.g., via the Internet or other network) tocomputing systems of box offices, promoters, artist managers, venueset-up personnel, social network systems, and/or potential ticketpurchasers. Thus, the ticket system may receive and/or provide fordisplay information and/or instructions described herein to one or moreof the foregoing networked systems and/or other systems.

Certain embodiments receive and utilize information, such as eventticket sale information, timing of event, occurrence of competingattractions, and/or other information to set initial pricing and/or toadjust previously set pricing of event tickets. Certain embodimentsprovide interactive seating maps configured to facilitate userunderstanding of the available seats, prices, available discounts,seating packages, etc., by providing a unified view (including agraphical representation) of what may be a complex set of prices andpromotions.

With respect to ticket pricing, certain embodiments utilize a model withhigh pricing granularity, optionally determined by statistical analysisand/or other model in combination with price level flexing/adjustment asa function of at least sell through (percentage or amount of availableevent tickets actually sold). Such high granularity can be two or moretimes the conventional granularity of four pricing points. For example,8, 10, 16, 32, 64, or other number of pricing levels may be utilized,where different seats or seating sections can be associated withdifferent pricing and where prices can be increased or decreased from afirst pricing level to a second pricing level.

This increase in granular price levels enable ticket pricing to be setor adjusted to more precisely match user demand and/or predicted userdemand. However, certain embodiments optionally set the granularity lowenough of avoid or reduce operational inefficiencies and customerconfusion (e.g., no more than 64 pricing levels).

Certain embodiments estimate demand and set ticket prices using thepricing levels or event-wide based on a number of characteristicsoptionally including, but not limited to, some or all of the following:artist, similar artist activity, recent metropolitan area activity, orday of show. Certain embodiments take into account venue sightlines inpricing tickets for a given event at a given venue.

Still further, certain embodiments combine events, such as sporting,theatrical, or concert events into a season package or a partial seasonpackage. Such a package may include high or medium demand events andrelatively lower demand events to thereby enhance ticket sales for thelower demand events. The grouping may be selected to as to achieve acertain desired level of ticket sales for a given season. Demand may bemeasured by actual tickets sales for other events that involve a givenperformer/performance (e.g., a musical performer/artist, a sportingteam, a play, etc.) and/or that involve a similar performer (e.g., aperformer in the same genre as the performer that is being packaged).

For example, certain embodiments perform pattern matching on sales ratesutilizing automated tools that analyze sales rates of a given event andcurrent and/or past comparable events to determine the likelihood thatcertain seats/sections/price levels may or may not sell out at thecurrent set price, and to indicate whether price changes may or may notbe recommended in order to sell out or to achieve other sales goalsand/or whether certain events should be packaged together. By way ofexample, an event may be determined to be comparable using one or moreof the following factors and/or other factors:

performer/artist (e.g., is it the same artist)

genre (e.g., is it the same genre of music)

venues (e.g., is it a similar sized venue, is it an outdoor venue, etc.)

time of year of event;

time of day of event;

sales;

existence of competing attractions at the same or within a specifiedrange of time and/or within a specified distance of the event (e.g., apopular sporting event, concert, new blockbuster movie, etc.).

Still further, certain embodiments address the challenge presented withrespect to enhancing tickets sales, revenues, and/or profits presentedby season tickets and “holds” (tickets held for the performer, promoter,or other entity, that are not available for sale to the general public).Season tickets and “holds” tend to consume much or all of the mostelastic, high-demand inventory in certain venues, and yetconventionally, are not appropriately priced or offered for sale atappropriate times.

Yet further, certain embodiments may be utilized to enhance grossrevenues, net revenues, and/or the number of seats filled/tickets sold.Certain embodiments may be utilized to reduce certain types of resaleactivity (e.g., resale activities that may not be in the publicinterest, such as, in certain instances, ticket scalping).

Certain example embodiments will now be described with respect to thefigures.

FIG. 1 illustrates an example architecture. A computer system 102, whichmay be a ticket system, may be in the form of a server that hostsprogram code configured to execute processes described herein and toprovide for display over a network to one or more terminals (e.g.,client computers 112, 114, 116, 118, 120) some or all of the userinterfaces discussed herein. In addition, the system 102 is configuredto receive user requests, instructions, and/or data provided via theterminals, carry out the user requests and/or instructions, and accessdata from and store data to one or more data stores (e.g., venuedatabase 104, pricing database 106, ticketing database 108, user accountdatabase 110, social network database, etc.). The system 102 may becoupled to the terminals and/or other systems via one or more networks112. By way of example, the terminals can include some or all of thefollowing:

-   -   a venue operator terminal 112;    -   a box office terminal 114;    -   a promoter terminal 116;    -   a ticket seller terminal 118;    -   a ticket purchaser terminal 120.

The system 102 enables a user to define a representation or model of avenue for an event (e.g., to setup the event). For example, as describedin greater detail herein, various user interfaces are provided via whicha user can define ticket pricing (e.g., pricing levels) for individualseats and/or groups of seats (e.g., price breaks). Further, certainembodiments enable a user to model the impact various ticket prices haveon ticket sales and revenues for an event. For example, as described ingreater detail below, a user may change the price level for one or moregroups of seats, and the system will calculate a projected effect onticket sales and revenues (e.g., from ticket sales and/or concessions).The system will then generate a report that is displayed to the userthat reports the projections.

The system may generate a detailed summary for executive review, whichmay then be transmitted to (and/or printed out and provided to) one ormore designated recipients (e.g., whose approval is/are required inorder to implement the event setup or changes thereto), whose approvalor disapproval may be recorded by the system. The system may also keepand store an archive of certain or all changes made to the event setup.The approved detailed summary may be physically and/or electronicallystored with or in association with a related contract (e.g., a contractbetween the ticket seller, venue, promoter, and/or performer/team).

Certain embodiments enable a user to designate and store a rank for eachseat, seat block, section and/or other seating areas (e.g., where theuser can select a seat displayed in a seat map and enter a ranking codesuch as a number, or where a formula can be applied for each seat thattakes into account seat distance from the performance/stage, viewingangle relative to the performance/stage, seat height relative to thefloor/performance/state, and/or other factors). The ranking maycorrespond to an objective or subjective quality ranking (e.g., where afirst row, center seat, may have a ranking of one, and where a rearmostseat at the highest seating level may have a ranking of 18,000). Thisranking may be used to designate the selling order of seats by thesystem (e.g., in response to “best-available” seat requests, where auser requests a ticket to whatever is designated as the best availableseat). The seat ranking may also be used for ranked seat auctions, asdiscussed elsewhere herein.

Further, the system 102 receives substantially real time ticket salesinformation for one or more ongoing events, and reports the informationto a user (e.g., reports an event ticket sales rate, the number of soldseats, the number of unsold seats, the number of held seats, thepercentage of sold seats, a projected sell-out time, event web pagevisits, event web page conversions to sales, cumulative sales by day asa percent of original net capacity, cumulative audit gross by day,and/or other information discussed herein). The system 102 also hasaccess to, and is configured to provide for display historicalinformation for events that have concluded, including some or all of thetypes of information provided for ongoing events.

The system 102 optionally utilizes the event seating and ticket pricinginformation to provide user interfaces for display to ticket purchasers.For example, the user interfaces may display a seating chart colorcoded, icon coded, and/or text coded to indicate seat availability,prices, whether the seats are wheelchair accessible, whether a specialcode is needed to purchase ticket for a seat, whether the user hasalready purchased a ticket for the seat for the event, etc. The ticketpurchaser user interface may provide a control via which the user canspecify filtering criteria (e.g., ticket price, viewing quality, whethera special offer is available, whether the a ticket for the seat is heldby a friend of the user, etc.), wherein the user interface willhighlight individual seats and/or seating sections that meet the filtercriteria. Optionally, the user may select (e.g., by pointing at orclicking on) an individual seat and/or seating section, and the ticketpurchaser user interface will access and display additional informationregarding the eat (e.g., whether a special password/offer code isrequired to purchase tickets for the seat, a seat number, a seat rownumber, a seat section number, face price, ticket related fees, combinedface and fee prices, view information, whether alcohol is permitted,whether the seat is in the shade, etc.).

Optionally, the system 102 has permissions stored for various users. Thepermissions may be specified by an overall system of event manager. Thepermissions may, for example, specify who is allowed to view certaininformation (such as some or all of the information discussed herein),who is allowed to change properties of one or more items (e.g., ticketprices, price breaks, holds, seating setups, and/or other parametersdiscussed herein), who is allowed to propose changes to a decisionmaker, and/or who is allowed to approve changes.

The system 102 may be connected, via the network, to a social networksite system 122. The social network site system 122 may include adatabase storing user information, photos, event information, and userand other pages, and connections between users and items, such as sharedcontent, photograph/video tags (wherein a tag may be metadata, such as akeyword (e.g., a person's name) or term assigned to an item ofinformation, such as a person in a photograph), friend relationships,etc. The system 102 may obtain information regarding users from thesocial network site system 122. For example, the system 102 may requestand obtain names, photographs, the identifications and photographs ofusers' friends, information on user social events, postings, etc. Thesystem 102 may also create events, wherein users may view postingsregarding events and receive invitation to the events via the socialnetwork site system 122. In certain embodiments, if a user responds toan invitation or indicates which event seats the user and/or friendswill be sitting in, the system 102 may construct a post and transmit thepost to the social network site system 122 for display via a webpage orother interface.

Thus, the computer system 102 enables events to be configured,projections and modeling to be performed, real-time information to begathered from multiple sources, analyzed and reported, and/or ticketsales to be managed and made via interactive seat maps.

FIG. 1B illustrates an example process that may be carried out by system102 or other configured computerized systems. At state 150, a userselects an event and/or venue to be setup (e.g., from a menu, by typingthe event name and/or venue name into a corresponding field, orotherwise). At state 152, the system accesses and/or generates a seatingmap of the venue, which is provided for display on a terminal of theuser engaged in establishing price breaks, where seats in a given pricebreak are to be priced identically or substantially identically. Theseating map may be coded using color, icons, text, and/or animation toindicate various attributes (status, price level, etc.) of seats and/orseating areas.

In an example embodiment, at state 154, the user may specify pricebreaks by selecting, using a mouse, touch screen, or other userinterface, a section or groups of seats displayed via the seating map,and assign a price break identifier to the section or group. (e.g.,group A, group B, or Group 0, Group 1, etc.). Optionally, a userinterface is provided via which a user can textually enter seatidentifiers (e.g., section identifier, row identifier, individual seatidentifier) for a beginning seat and an end seat of a price break tothereby define a price break for the beginning and end seats, and theseats therebetween. Optionally, the user can identify certain seatswithin or outside of a price break as being “hold” seats (not for saleto the general public). Example interfaces for setting price breaks aredescribed in greater detail elsewhere herein. Optionally, a user mayassign seat, seat block, section and/or other seating area rankings,which correspond to relative seat block, section and/or other seatingarea quality or anticipated desirability.

At state 156, event creation is performed. In an example embodimentwhere multiple price breaks are to be established, an event is defined,in part, via the price breaks, where a given physical section and pricebreak combination is assigned to an individual section. The number ofsections (and the number of seats per section) may be used forestimating the available event capacity.

At state 158, a pricing matrix, setting pricing levels for some or allof the price breaks is generated. The price levels may be manually,automatically, or using a combination of manual and automatic processes,be generated based on preferences, historical information, and/or otherparameters, such as some or all of the following:

artist/performer preferences/experiences;

promoter/manager preferences/experiences;

ticket seller preferences/experiences;

ticket media and/or transferability. For example, some tickets may betransferable and some tickets may not be transmitted. By way of furtherexample, in certain embodiments, a ticket format may be configured toeliminate or restrict resales, such as when the ticket is avirtual/paperless or electronic ticket (e.g., where an access right isassigned to a pre-existing document, such user credit card a debit card,a driver's license, a passport, and/or a state issued identificationcard, and the document is presented in order to gain access to the eventby scanning the document and determining whether a right of entry isassociated with the document), an emailed ticket or downloadableprintable ticket, or may be in the form of a more easily transferredphysical ticket, such as a paper or plastic ticket specifically made forproviding event access;

current ticket sales information for the event and/or for similarevents; and/or

historical ticket sales information for past events that have ended.

At state 160, initial price levels and/or sell sequence(s) are assignedto the price breaks, and the assignments are stored in memory. The sellorder may be used to define the order in which seats/price breaks are tobe offered for sale, where certain price breaks may be offered for saleat the same time, and certain price breaks may be sequentially offeredat a latter time(s).

At state 162, the event setup is optionally transmitted to one or moreusers for approval prior to offering the tickets for sale (e.g., via anemail that contains a link that when activated, causes the recipient'sbrowser or other viewer to display user interfaces displaying theinformation to be approved). For example, approval may be requested fromthe artist/performer and/or venue operator for review (e.g., so thatthey can review the price levels, price breaks, specified seatingcapacities and availabilities, etc.). At state 164, a determination ismade as to whether the requested approval has been received. If not,optionally, a follow-up communication is transmitted to the user(s)asking for approval.

If the reviewing user has responded but has requested modifications toone or more items (e.g., to the price levels, to the price breaks, tothe assignment of the price levels to the price breaks, to the sellsequence, etc.), then at state 166 the various items may be adjusted viathe system, and the adjustments stored in memory. Optionally, requestsfor approval of the adjustments may be transmitted to one or moreselected users.

Optionally, certain seats or price breaks may be designated as subjectto future pricing modifications even after ticket sales for the eventbegin, and certain seats or price breaks may be designated as fixed (notsubject to change once ticket sales have begun).

At state 168, event tickets are offered for sale (e.g., via onlinewebsites, via mobile apps, via physical outlets, via phone or otherwise)in according with the pricing set as discussed above.

Example interfaces for setting price levels and setting up events aredescribed in greater detail elsewhere herein.

The event setup user interfaces may be used during negotiations betweeninterested parties (e.g., the performer/team, the promoter, the boxoffice, the ticket seller, etc.) to set up different potential models ofevent, which may be used to estimate the potential revenues and/orticket sales given different set-up parameters (e.g., different numberof price levels, different ticket prices, different number of heldseats, different number of killed seats, etc.). Once the ticket setup isagreed upon, the setup user interfaces may then be used to provideinitial instructions to the venue box office and/or other entities onwhat the initial event setup is, and tickets may be sold in accordancewith the setup. The event setup user interfaces may also be used aftertickets are placed on sale to dynamically change the event setup (e.g.,to change which seats are assigned to which price levels, the face valueof unsold seat tickets, the number of held seats, etc.). Certainembodiments may include a data interface configured to receive dynamicpricing from a pricing engine and are configured to change the seatticket pricing accordingly, where the changes may be automaticallyreflected in the change list.

An example event creation process will now be described in additionaldetail. Price breaks are set for a given event(s) and/or venue(s). Assimilarly discussed above, price breaks relate to setting prices forrespective sets of seats, such that prior to the start of ticket salesfor those seats, the open seats within a given price break will bepriced identically or substantially identically. Optionally, “holds” maybe put on one or more seats in a given price break.

Over time, or as the result of initial modeling, the price levelassociated with a price break may be dynamically changed (e.g., by auser or system authorized to change pricing). For example, the pricelevels may optionally be increased or decreased based in whole or inpart on ticket sales. For example, the price levels may optionally beincreased or decreased based on one or more of the following factors:

-   -   the quantity of tickets sold for the event and/or specific        seating areas for the event,    -   the rate of ticket sales for the event and/or specific seating        areas for the event,    -   the quantity of tickets sold for other events with the same        performer or for one or more similar performers,    -   the rate of ticket sales for other events with the same        performer or for one or more similar performers,    -   the sale of a specified seat or set of seats in the inventory        the expiration of a timer or a date/time alarm, and/or

other parameters.

At the time of such changes in pricing, unsold ticket inventoryassociated with a given price break may be shifted to a new price leveland its associated pricing. Seats sold prior to such shifts, andoptionally available seats in the same row in the same seating section(or other seats designated in a data store with an indication that theprice level is not to be changed for the event and/or as determined viaa rule), as this sold inventory may remain at the price level at whichthey were initially sold (e.g., to facilitate appropriate refunds and/orfor customer relations).

An example graphical tool, illustrated in FIG. 2, is optionally providedvia the system for display on a user terminal to enable a user (e.g., anauthorized user having appropriate permissions) to view and set suchprice breaks. The tool may be hosted by the system 102. The graphicaltool provides an interface that eases the definition and viewing ofareas of like quality in the venue, using, for example, color coding.Different colors may be used to reflect different price break areasand/or different price levels applied to such price break areas. A pricemay be assigned to seats (e.g., via a field that associates a color,individual seats, specified rows, and/or specified sections/areas) viaone or more fields.

For example, red, olive, green, blue, teal, orange, etc., may be used toindicate different price breaks. Optionally, more muted or pastel colorsmay be used to indicate relatively low grade/inferior seats, andbrighter or primary colors may be used to indicate relatively highergrade/superior seats. Other visual indications may be used as well(e.g., flashing seat icons may be used to indicate higher grade/superiorseats).

For many ticketed events, certain tickets are held by the artist,promoter, and/or venue, and so are not made generally available to thepublic (at least in conjunction with the initial ticket sales to thepublic). These tickets are sometimes referred to herein as “holds”.Often held seats are among the more or most expensive and desirableseats.

The management of holds may significantly impact ticket sale revenue.This is because the initial hold setup is often not tightly coupled withevent capacity and pricing decisions. Further, the practice of holdsoften eliminates or reduces public access to the highest priced seats,where on-sale price adjustments tend to be more relevant to meetingdemand. Further, while many held seats are eventually released to thepublic (e.g., because the “holder” of the held seats is not going to usethem), conventionally unused holds are often released to the market forpurchase by the general public too late in the event life cycle to beconsumed by the market place effectively. Thus, many of the valuablereleased held tickets remain unsold, or have to be sold at a discountrelative to the face value or relative to what they could have been soldfor at an earlier time. Additionally, because of lack of adequate toolsand inefficient, time delayed communication, holds are often placedafter capacity and pricing decisions are made, further leading to aninefficient sale of tickets.

In order to overcome some or all of the foregoing challenges, certainembodiments provide modeling tools that enable pricing and capacitydecisions to be made with allowances for the number of holds in a givenprice level so that capacities can be appropriately expanded (e.g.,additional seats may be added and/or certain held seats may bereassigned to be on-sale to the general public) to allow the public toaccess and purchase seats at more expensive price levels.

FIG. 3 illustrates the graphical tool of FIG. 2, with “holds” visuallyindicated (e.g., in black). Thus, a user managing the assignment of heldseats and the assignment of price breaks and price levels can view thelocation and concentration of held seats, as well as the price levels ofadjacent, non-held seats. This enables the user to quickly evaluatewhich seats should be designated as held seats, and to change suchdesignations so as to enhance revenue and/or access by the generalpublic.

FIG. 4 illustrates a user interface that depicts a high level view of avenue seating chart, color coded to indicate price breaks and aneditable yield calculation tool panel listing the price breaks andvarious example parameters, discussed in greater detail below. In thisexample, there are 28 price breaks/strata (although there can be greateror fewer price breaks), in contrast to the more typical four pricebreaks.

The example yield calculation tool panel enables a user to specify aseat count for a price break, the face value/price level of a ticket ina given price break, the “all in” cost of a ticket in the given pricebreak, and an estimated percentage of tickets that will be sold for thegiven price break at the given face value/price level. Some or all ofthe foregoing values may also be read from a database (e.g., byactivating an import control to import a file, such as a CSV (commaseparated value) formatted file), or may be calculated (e.g., by aforecasting tool).

The yield calculation tool then calculates (e.g., in response to a useractivating a “calculate” control or automatically in response to a userentering a parameter change) the total dollar value of the tickets thatare predicted to be sold for a given price break, a total grosspotential based on ticket face values, and a total gross potential basedon all-in ticket values (although the tool may provide less oradditional information). All-in ticket values or prices relate to theprice that would paid by the ticket purchaser (e.g., the ticket facevalue, facility charge, shipping fee, etc.), or a subset thereof.Generally, although not necessarily, the all-in price will be greaterthan the face value of a given ticket. The calculated values can beexported to a file (e.g., a CSV file) upon activation of an exportcontrol by a user. Optionally, the reported percentage of tickets soldmay be adjusted to take into account ticket holds (e.g., where theticket holds are not included in determining the denomination of thefollowing: (tickets sold for a give price break)/(total ticketsavailable for the given price break)

Certain embodiments provide tools that shorten the timing gap betweencapacity decisions and holds management by allowing holds to be placedmanually (e.g., wherein a user can click on a set to indicate it is aheld seat). Further, such tools enable holds to be transferred fromtheir owners and sold via the ticketing system through to the generalpublic to increase revenue, optionally without the use of ticket brokersor scalpers, which typically buy and resell tickets. For example,certain embodiments provide a user interface via which an authorizeduser can select held seats via the interactive user interface, andchange the designation to an on-sale designation.

FIG. 5 illustrates an example user interface that further facilitatesthe management of holds. Optionally, in response to a user action (e.g.,clicking on or hovering over a given seat icon, entering a seatidentifier into a corresponding field, etc.), the user interfacedisplays information accessed from a system database. For example, theuser interface may display the section, row, seat number, price level,price break, and/or hold states for the corresponding seat or groups ofseats. Further, a report is optionally generated in real time,reporting, for a given event or set of events, the total number ofseats, the total number of open seats, the total number of sold seats,the total number of held seats, the total number of inquiries (e.g.,tickets for which a purchase process has begun but has not yet beencompleted, such as seat tickets placed in a user online shopping cart),the total actual gross, and the total potential goal (assuming all theseats are sold).

FIG. 6 illustrates another example user interface of a reporting toolthat enables a decision maker to efficiently manage multiple events byproviding the decision maker with direct access to the status of a venueseat (e.g., the price assigned to a ticket for the seat, an indicationas to whether the seat is held by the venue or promoter, etc.) and toexecute changes to the seat status directly, via a seat map. Thus, incertain embodiments, the decision maker can execute price changesdirectly, without having to issue requests for status from othersinvolved in the ticketing process, such as box office executors.

Certain embodiments facilitate the processing and display of data formultiple events, as well as the management of ticket pricing, pricebreaks, and holds for multiple event. As illustrated in FIG. 6, anexample online information distiller tool filters and/or aggregatesticket sales information and pricing information for multiple events.For example, the distiller can generate reports for multiple eventsincluding, on an event-by-event basis, and in aggregate across multipleevents, some or all of the following information:

PL (Price Level)/PB (Price Break) ratio;

the number of seats for which tickets have been sold;

the number of open seats (seats available for purchase by the generalpublic);

the number of QOpen (qualified open seats are seats available forpurchase by public purchasers that have a specified access code or areusing a specified brand of credit card); the number of held seats; therate of ticket sales;

an indication as to the acceleration/deceleration of sales (e.g., salerate increasing, decreasing, steady);

the date and time of last ticket sale;

the projected PB/PL sell out;

the event release rate/percentage (wherein certain seats may bedisplayed as held seats or sold seats until the sales rate reaches acertain or specified threshold, at which point some or all of such seatshave their status change to open or qualified open (e.g., the ticketsare released for purchase by the public). This technique enables a slowselling event to appear more popular as not as many seats are shown asavailable at a given point in time); and/or

the event rate (as similarly discussed with respect to FIGS. 21P and21Q, the event rate may be used to determine what type of user interfaceto display and/or the mechanism for letting users specify which ticketsthey would like to purchase).

In addition, a user can specify a watch list, which is then stored inmemory. The system accesses the user's watch list, and then aggregatesand reports the status of ticket sales for an event added to the watchlist by the user. For example, the watch list report can indicate someor all of the following and/or other information:

-   -   whether the event is sold out (e.g., based on the number of        available seats and the number of tickets sold);    -   whether the event will be sold out soon, such as within a        specified period of time, such as within 12 hours, 1 day, 1        week, or other specified time frame (e.g., based on the number        of available seats, the number of tickets sold, and the rate of        ticket sales);    -   whether the ticket sales for the event are moderate (e.g., based        on the number of available seats, the number of tickets sold,        and/or the rate of ticket sales);    -   whether the ticket sales for the event are slow (e.g., based on        the number of available seats, the number of tickets sold,        and/or the rate of ticket sales);    -   PL for the event;    -   PB for the event;    -   opens;    -   the sales rate for the event;    -   the number of tickets sold for the event.

Similarly, the watch list report may generate and report information forall ongoing events being monitored, or a subset thereof, the informationincluding some or all of the following: the status of ticket sales(e.g., sold out, almost sold out, moderate, slow, etc.), the PL, the PB,the number of opens, the percent of available tickets sold (including orexcluding held tickets), the actual and/or predicted date/time of a sellout of an event, an event release rate.

Optionally, based on the ticket sale status and/or other informationdiscussed herein one or more of the following actions may be taken(automatically and/or manually):

-   -   reduce the number of ticket holds (including determining which        held seats are to be offered to the general public);    -   increase ticket prices for certain or all seats/price breaks;    -   decrease ticket prices for certain or all seats/price breaks;    -   offer free or for cost ticket upgrades, giving ticket purchasers        tickets for relatively higher quality seats than those they had        selected to purchase;    -   increase advertising/marketing expenditures related to the        event;    -   decrease advertising/marketing expenditures related to the        event; and/or    -   select medium/channels/target demographics/segments for    -   advertising/marketing for the event.

For example, if the one or more selected reported data items/informationsatisfies a specified threshold one or more of the above actions may betaken.

In addition, historical ticket sales information for past events and/orcurrent ticket sales information for ongoing events may be used by aforecasting tool to determine the effect (e.g., “what if” scenarios) ofraising or lowering ticket prices on overall gross sales potentialand/or to determine the risk of the gross sales or other sales amountfalling below a guarantee made by the ticket seller to the venue, theperformer, the promoter and/or other entity.

FIG. 7 illustrates an example forecasting tool user interface. A usercan select predefined report formats that specifies what data is to bereported and the presentation format. For example, a report may specifythe total number of seats, the total number of open seats, the totalnumber of sold seats, the total number of holds, the total number ofinquiries, the actual total gross, the potential total gross, and a“what if” total gross. The “what if” total gross may be calculated basedon a user specified “what if” face value (wherein the “what if” facevalue may be specified to be higher or lower than a current face value),wherein the “what if” value may be specified via the grid. The grid mayalso be used specify and/or display a price level, a seat category, aseat type (e.g., adult, child, open, etc.), a face value, a seat count,a revenue potential, and an actual revenue. A navigation control enablesa user to specify whether all or a zoomed portion of the seating chartis to be displayed.

When an event has been completed (e.g., after the conclusion of aconcert that is part of a concert tour by a performer or after asporting event), data leading up to the event and during the event maybe stored in a centralized data store, and optionally utilized to makedecisions on remaining dates of a concert tour or sports season, and/orthe data may be extrapolated for use with a similar tour. For example,as elsewhere described herein, the data may be used to price tickets forone or more price breaks, to determine venue seating configurations, todetermine how many shows to schedule at a given venue for a givenperformer, to determine which acts should be scheduled together for agiven event (e.g., to pick an opening act for a headlining act), etc.

An example flex execution tool will now be described, with reference toFIG. 8, which illustrates an example flex execution tool user interface.Controls are provided via which a user (e.g., a promoter, performer, orother authorized entity) can change a price for a specific seat or a setof seats (e.g., for a price break). For example, the user can specifythat the price level for a given price break is to be changed to anotherpredefined price level. By way of illustration, there may be 32different predefined price levels, and the user can change the pricelevel for a given price break from price level 15 (e.g., $28 per ticket)to price level 16 (e.g., $32 per ticket). The tool calculates anddisplays the impact the price change will have on revenues (e.g., thenet impact on the potential gross), optionally in substantiallyreal-time. In conjunction with the report on the impact on revenues, thetool may report how many seats were affected by the instruction tochange price level, the previous price level, and the proposed pricelevel. Thus, the flex execution tool can be used by a user, such as apromoter, to modify price levels based at least in part on informationreceived from monitoring tools described herein, and have the impact ofsuch modification substantially immediately reported to the user.

FIG. 9 illustrates an example on-sale distiller tool user interface,similar to that illustrated in FIG. 6. The on-sale distiller tool userinterface is configured to report, optionally in substantially realtime, information regarding ongoing ticket sales, as well as historicalticket sale information. The user interface includes a notification areathat alerts the user regarding actionable pricing recommendations(provided by another user and/or automatically by the system). Forexample, the recommendations may be based on sales rate and/or totalinformation for an entire event and/or one or more selected seatingsections of a venue from one or more ongoing and/or past events.

The example on-sale distiller tool user interface optionally includes awatch list user interface. A user can add one or more areas of interestfor one or more events. For example, the user can specify thatinformation (e.g., the sales rate, the number of open seats, the numberof sold seats, a report as to whether the price break/price level issold out, whether sales are moderate, whether sales are slow) regardingprice level 1/price break 3, price level 2/price break 5, and pricelevel 2/price break 7 is to be continuously updated in the watch listarea.

Certain items of information, such as the alerts may be visuallyemphasized (e.g., a bright color, a bold graphic, flashing symbol ortext, etc.) to better catch the attention of the user. For example,certain items of information can be color coded so that the information,or changes thereto, will be emphasized to catch the user's eye. Forexample, a “sold out” alert may be color coded in blue, a “sold outsoon” alert may be color coded in orange, a “moderate” alert may becolor coded in yellow, a “slow” sales alert may be color coded in red,and so on.

An “all items” area reports information on additional events, pricelevels/price breaks, etc. For example, the “all items” area may reportsome or all of the information types provided via the watch list reportand/or additional information, such as percent of tickets sold,projected date/time of a sell out (if available) of all thecorresponding tickets, the event ticket release rate, etc. The user canspecify to the system that the report is to be sorted based on one ofthe information types.

As discussed above, the on-sale distiller tool user interface optionallyalso playback historical ticket sales information, thereby enabling theuser to view sales patterns and trends. In the distiller, this salesinformation may be displayed and viewed with numbers and projectionsbeing independently indicated, thereby enabling a user to view seatschanging status on the map.

A “pause” control is provided which enables a user to pause the updatingof the reported information, which lets the user study the informationat a given moment in time. The user then may resume the updating toenable the updating to resume.

FIG. 10 illustrates an example price break report. The report indicates,for a given price break, the price level(s), the face value at a givenprice level, and the all in face value (e.g., the face value of theticket plus fees and service charges) at a given price level. An auditdata stream on the system includes information about the quantity oftickets sold at each price break and at which price level. This providesthe user with a historical record regarding the effectiveness of priceflexing.

Real-time information may be provided as well (e.g., accurate to within2 minutes or other time period, such as less than 1 minute or less thanminutes). The real time information may be utilized to show wheretickets are selling quickly and/or slowly so that prices can be adjustedappropriately. For example, if certain areas have ticket sales less thana desired amount and/or at less than a desired rate, the user performingpricing can adjust ticket prices in those specific areas downward tostimulate and increase ticket sales. By way of illustration, certainembodiments include a substantially real-time graphical sales reportthat displays some or all sales on a graphical seat map.

FIG. 11 illustrates an example real-time sales map. The illustratedreal-time sales map displays substantially current sales information ona venue map with a legend showing counts of sales, opens, and/or holds.Information may be provided on a price break-by-price break basis,and/or seating section by section basis and/or for the overall event onthe percent of tickets sold, open, and/or held, the rate of ticketsales, the acceleration or deceleration of tickets sales, a projectedamount of time the available tickets will be sold out, the sales rate ofa price break or section relative to the entire event, etc. Individualseats may be color coded to show sale status (although textual,graphical, and/or other indicators may be used to show sales status,pricing, etc., may be used instead or in addition).

FIG. 12 illustrates another example user interface, providing, via agraph, substantially real-time sales rate information. In the exampleillustration, a ticket sales rate for a first price break (PB2) and aticket sales rate for a second price break (PB3) are graphed by thesystem. Ticket sales rates for fewer or additional price breaks, pricelevels, and/or events may be selected by the user and then graphed bythe system. In addition, the example user interface textually providesadditional information for one or more price breaks, price levels,and/or events. For example, some or all of the following information maybe displayed:

Number of tickets sold, open, and Qopen (qualified open, which may be anattribute applied on base status of seats, to thereby—sub-allocateinventory to public, wherein a user has to enter a promotional code orpassword, or use a certain brand of credit card in order to be entitledto purchased a qualified open seat;

Number of tickets held, the percent of tickets sold, the time/date ofthe last ticket sold;

Sales rate (e.g., tickets per minute), and a report as to whether saleare accelerating, decelerating, steady, etc.;

Projected date/time of a ticket sellout;

Projected date/time of ticket sales stagnation (wherein the system mayextrapolate from a current rate of sales and a template curve of anexpected sales curve (e.g., a decaying curve, which may be selectedbased on historical sale profiles of similar event), fit curve throughevent ticket sales data points, and if the sales fall below a certainthreshold, project when sales rate will fall below a certain level, suchas near zero event ticket sales per day or other relatively low ratethat indicates that ticket sales are stagnating);

Event release rate.

In addition, the user interface illustrated in FIG. 12 provides auser-defined watch list, and an “all item” information display, assimilarly discussed above.

A price break/price slot detail report, such as that illustrated in FIG.13, may be generated that provides, for a given price break, pricelevel, and/or section the percent of tickets sold, open, and/or held,the rate of ticket sales, the acceleration or deceleration of ticketssales, a projected amount of time the available tickets will be soldout, the sales rate of a price break or section relative to the entireevent, etc. In addition, controls are provided via which a user caninstruct the system to add a graph to the user interface illustrated inFIG. 12 on the watch list or on particular slot (e.g., where a user canselect a price level for which substantially real time sales activity isto be displayed).

FIG. 14 illustrates a user interface via which a user can specify a timeperiod for which sales rate and/or other information is to be graphed orotherwise reported. In addition, an interface is provided via which theuser can specify that price breaks having a greater than specifiedpercentage of sell-throughs (e.g., the percentage of seats sold in aselected price level are to be ignored/not reported (e.g., if there areno or substantially no remaining seat tickets available at the selectedprice level).

Other reports (provided in substantially real-time and/or after a delay,in non-real-time), can include graphs of, for one or more venues and/orone or more shows at a given venue:

-   -   web page visits on a day-to-day basis (or other period of time),        an example of which is illustrated in FIG. 15;    -   web page conversions (where a web page visit resulted in a        ticket sale), an example of which is illustrated in FIG. 16;    -   cumulative sales by days as a percent of “original” net        capacity, an example of which is illustrated in FIG. 17;    -   cumulative audit gross by day, an example of which is        illustrated in FIG. 18;    -   daily average sold ticket price, an example of which is        illustrated in FIG. 19;

As similarly discussed above, optionally the graphs can include graphsfor multiple venues for events associated with a given performer and/orfor multiple events/shows at a given venue, enabling a user to visuallycompare tickets sales for different venues and adjust ticket pricesaccordingly. For example, the graphs provide metrics to interestedparties involved in ticket pricing (e.g., artists, promoters, venues) toprovide an understanding of their events' performance and how pricechanges and inventory management affect sales. Thus, in certainembodiments, a user can simultaneously view sales and/or other eventdata for multiple events.

Further, reports can be generated that provide the number of seats sold,the total gross, and the average sold price per ticket, and the numberand/or percentage of tickets resold for given venue section (e.g.,floor, box, lower 1, lower 2, upper 1, upper 2, etc.).

Thus, seating pricing and price breaks may be dynamically set using theinterfaces discussed above. Optionally, in addition or instead, thefollowing techniques may be used for setting price breaks. In theexample embodiment where there are multiple price breaks, an event iscreated from the price breaks within a given physical section and pricebreak combinations being assigned to an individual seat block. A seatblock is a group of seats with certain identical attributes (e.g., thesame price level, near the same exit portal, having the same sectionname, in the same area of venue, in the same row, etc.). Thus, a seatblock may be smaller than a physical venue section (e.g., may be smallerthan a venue's orchestra, lodge, or balcony sections). Different pricelevels may be assigned to different seat blocks. Having more seat blocksthan physical venue sections enables a higher degree granularity ofsection pricing, and thereby enables various seat blocks to be moreappropriately priced. Seat blocks may optionally be large enough tohandle all seats that potentially could be added to the manifest withthose seats being in an open status. Thus, for example, if a venue eventhas about 280 degrees of visibility about the stage, with about 80degrees behind the stage completely blocked, the seats behind the stagemay be marked as unavailable, the seats in front of the stage may bemarked as available, and the seats on the border between the availableand unavailable areas may be marked a provisionally unavailable orprovisionally available, subject to review of an appropriate authorizedperson (who may verify whether the stage visible or not from the borderareas). Thus, there may be enough seat blocks defined to provide forseats in the border areas.

In addition to the process of defining seat attributes (e.g., commonattributes, such as price level, venue area, etc.) for a given seatblock, the price break identifier may be placed in a sub-price levelfield (also referred to as a price break field). The price break levelfield may be used to indicate that specified sections or seating areasat the same price level are to be separately reported with respect toticket sales and/or ticket availability. For example, if seats in abalcony area and seats in a floor area are priced identically, a salesreport requesting sales information on $100 seats may break out salesfor the balcony and sales for the floor area. The count of seat blocksgenerated is recorded, and this information may be used in estimatingthe available event capacity of the venue/event data structure. Afterinitial pricing is established, the sell order of the seat blocks may bedetermined.

Optionally, the seat blocks are defined or moved so that sequential seatblocks follow the natural or specified selling sequence of the venue.For example, the seat blocks may be assigned numbers sequentially if thecorresponding seat blocks are to be put on sale sequentially.Optionally, the process is automated using a pre-existing chart with agiven physical section assigned a unique seat block identifier.Additionally seat blocks may be defined in order to provide greatercontrol of the selling order. Optionally, a unique identifier may beassigned to a given seat ticket price including any associated discount,to thereby enable a user to request a report on the given uniqueidentifier, where a report is generated for the actual net pricing. Inan example embodiment, once the initial event setup is performed, apricing matrix may be defined.

A set of price levels is optionally established using event modelingstatistics, artist manager/promoter experience, and/or other informationin combination with the price break setting tool. Optionally, a range ofprice breaks may be set based at least in part on artist preferences orspecifications. Optionally, some or all of the seats and/or price breaksmay be designated for paperless ticketing (e.g., where a paperlessticket is associated, via a database entry, with a user identificationitem, such as a credit card or driver's license, which may then be usedto gain admission at the event venue). For example, certain seats mayhave a relatively low ticket price set, but may be designated aspaperless-only to ensure tickets got in the hands of true fans that willactually attend the ticketed event, rather than ticket brokers or othersthat purchase tickets with the intention of reselling them. By way offurther example, other, more expensive tickets may be designated aspaper or paperless, wherein the ticket purchaser can select the ticketformat.

For example, as similarly discussed above, the tool user interfaceillustrated may display, using color coding and/or other notation todesignate price breaks, held seats (e.g., seats held for the artist'suse, the promoter's use, for the venue's use, and that are not availablefor sale to the general public), seats associated with paperlessticketing, etc. The user interface aids the person(s) entering thepricing information to visualize seat grouping and to see gross and/ornet revenue potentials, as calculated by the system.

By way of illustration, the user can instruct the system, via a userinterface control, to color seats by price and/or by price break. Theuser can instruct the system, via a user interface control, to calculatethe average face value/price, the average all-in value/price, and theexpected number of available seats and/or the expected number of seattickets that will be sold. The user can instruct the system, via a userinterface control, to calculate the total gross potential value for thesale of the event tickets based on face value of the tickets and/or theall in value of the tickets (the face value of the ticket plus fees andservice charges).

A user editable table is optionally provided for defining a pricingmatrix. The table includes rows for a give price break, and columns thatinclude values for the ticket count of the price break, the face valueof the price break tickets, the all-in value of the price break tickets,the percent of tickets expected to be sold, and the number of ticketsexpected to be sold, and the total value of the tickets expected to besold (e.g., total face value and/or all in value). The user can changeone or more entries (e.g., the face value and/or the percent of ticketsexpected to be sold), and the system will calculate the resulting values(e.g., the new total dollar sales for a given price break, the new totalgross potential sales for face price and/or all-in price), etc. Controlsare optionally provided via which the user can zoom in or out of a givenseating section on the seating diagram.

Optionally, the system stores rules and permissions which are utilizedto determine who may change ticket prices for a given event, venue,performer, and/or promoter, as similarly discussed above For example, incertain cases, price changes from a requester may need to be approved bya venue box office (or other entity). Optionally, a user, such as theartist's manager or promoter, can enter price changes, such as via thevisual map. The price changes are automatically converted into anelectronic message (optionally after receiving a correspondinginstruction from the user). The electronic message is transmitted over anetwork to the box office system. The message may be stored in memory atthe box office system for later retrieval and/or the message can bedisplayed via the box office system when it is received. An authorizeduser at the box office can retrieve and view the message, and can thenapprove or deny the requested price change. Optionally, a messageregarding the approval or denial is automatically transmitted back tothe requester.

If the price change is approved, the approval is communicated to theticket system, and the price change is reflected, optionallysubstantially immediately (e.g., in less than 15 minutes, less than 10minutes, less than 5 minutes, less the 15 seconds, less than 5 seconds)online via web pages presented to potential ticket purchasers. Thus,certain embodiments enable rapid approval of ticket price changes andthe posting of the same to the ticketing website.

In certain embodiments, prior to final event creation, a matrix, such asthe example matrix illustrated in FIG. 22, may be created. The examplematrix is configured to indicate which price level may be initiallyassigned to each price break. Additionally, a list of potential pricelevels to which a price break could be flexed may be indicated.

The number of possible price level/price break combinations mayoptionally be limited by the number of sections in the venue and theaverage number of price breaks per section. The limitation on aparticular event may, in certain circumstances, be difficult to predictprior to actually building the event, so the process is optionallyperformed iteratively. An estimate can be given based on the count offree seat blocks. Price levels may be assigned to some or all seatblocks.

Optionally, the initial event setup for a venue may need to be reviewedand approved, such as by a performer, event box office, or other entity.The approval may be viewed via a terminal of the approver, and theapproval or disapproval of the event setup may be received over anetwork from the approver's terminal stored in memory in associationwith the initial event setup.

FIGS. 29A-H illustrate additional example event creation user interfacesfor a ticketed event. FIG. 29A illustrates an example opening userinterface which may be populated using data accessed from a ticketsystem database, and wherein values may be calculated (e.g., by theticket system and/or the user's client computer). The illustratedexample user interface includes the following functional areas (althoughother embodiments may have fewer or additional functional areas): areport area, an event data area, and seating map area, and a change listarea.

The report area (on the left-hand side of the example user interface),displays the following event level summary information and/or otherinformation:

-   -   an event name;    -   a system hosting the event model;    -   an event date and time;    -   an event venue;    -   yield data, including:        -   the total number of open seats (e.g., if ticket sales have            begun, the total number of seats available to the general            public, and if ticket sales have not yet begun, the total            number of seats to be made available to the general public,            optionally including seats that are quasi-open in the sense            that a special offer code or credit card associated with a            specific brand/issuer may be needed in order to purchase            respective seat tickets);        -   the total number of “solds” (the number of seats for which            tickets have been sold and are no longer available for an            initial sale);        -   the total number of holds (seats for which tickets are not            available to the general public, even when ticket sales            commence, but which could be later offered for sale to the            general public (e.g., tickets held in reserve for band            member families or for other private distribution));        -   the total number of “kills” (seats for which tickets are not            to be sold because of a physical impediment, such as seats            that are behind the stage and whose views of the performers            are completely blocked);        -   the total number of “inquiries” (seats for which tickets a            person is in the process of purchasing, such as by adding            them to their online shopping cart, but for which the            purchase is not complete (e.g., wherein if the purchase is            not completed within a certain period of time, the seats            status will be changed to “open” so that others may purchase            the tickets)).    -   Total Gross, including:        -   Actual gross ticket sales to date (the summation of the            number of tickets sold multiplied by the actual sale price            of the corresponding tickets);        -   Potential gross sales (e.g., the summation of, for each            price level, the price of a standard adult ticket at a price            level to which the seat is assigned, multiplied by the            quantity of seats at that price (where the actual gross may            be different than the potential gross where certain seat            tickets are sold at a discount, such as at a child rate),            optionally assuming no killed seats or instead, not            including anticipated ticket sales for killed seats).

The event data area, on the lower left of the user interface, provides agrid that presents, and enables the user to view, detailed statisticsand enables the user to decide what data and statistics are to bedisplayed. For example, a user may utilize column headings to organizeand sort the data. By way of illustration, the first column may be usedto define the sort basis. By way of example, in user interfaceillustrated in FIG. 29A, the first column lists the price levels (PL) bynumber (1, 2, 3, etc.), and so the data is sorted in price level order.In certain embodiments, a user may click on a column heading in orderfor that column's data to be used to determine the sort order.

A user may drag and drop columns in order to organize how the data isrepresented, and optionally the sort basis. As illustrated in FIG. 29B,the first column has been changed to “seat status”, and the data issorted alphabetically according to the seat status spelling. Inaddition, the column headings include controls (check boxes) via whichthe user can specify what data is to be summarized. In the exampleillustrated in FIG. 29B, “seat status” is selected.

Referring back to FIG. 29A, the event data displays a listing of pricelevels, and for respective price levels, the following information isprovided in respective columns: seat status (e.g., open, hold, kill,sold, in-cart, etc.) for seats at the respective price level, ticketface values (e.g., the non-discounted ticket prices) for seat tickets atthe respective price level, the seat count at the respective pricelevel, the revenue potential at the respective price level, and actualrevenue (actual sales) at respective price level. Other example columnsmay include seat type, price break, description, qualified open seats,etc. The example user interface illustrated in FIG. 29C includes acontrol box via which columns may be added or deleted from the eventdata grid.

In certain embodiments, a user may manually enter data into a givenfield, and the system will calculate the effect on data in other fields,to thereby enable a user to perform a what-if analysis. For example, theuser can change the ticket face value, seat count, and/or number ofseats having a specified status (e.g., open, sold, held, killed), andthe user interface will be updated to reflect the effect of the changeon other types of data, such as on revenue potential. Thus, the user cansee the effect of certain changes (e.g., on revenue, profitability,number of tickets that are likely to be sold, etc.) and decide whetheror not to actually implement those changes.

FIGS. 29D, 29E, and 29F illustrate example filtering operations.Referring to FIG. 29D, a user interface is provided via which the usercan specify filtering criteria, such as some or all of the followingand/or other filter criteria:

-   -   price level (current pricing scheme associated with        corresponding seats);    -   price break (set of seats logically grouped together, such as        seats in a certain common area, which can be shifted as a set        from one price level to another);    -   price group, location group, section group, additional group        (which may be used to specify other seat groupings, where a        given seat may belong to multiple groups, such as a “lower        level” group, bleacher group, 1^(st) base side group, 3^(rd)        base side group, etc., where a ticket purchaser may specify a        desired seat by naming the groups without reference to a visual        map (e.g., during a phone call with a ticketing agent or        interactive voice response ticketing system), and where        different seats within the same price level may be assigned to        different groups for reporting purposes;    -   “sections” (wherein a given section may be specifically named        (e.g., section 101)).

The seating map and the event data may then display/emphasize seats andrelated data that satisfies the user-specified filter. In addition,subtotals may be calculated for the selected items in the event dataarea.

FIG. 29E illustrates another example user interface, wherein the usercan specify one or more price levels for the filtering operation. In theillustrated example, price level 3 is selected. FIG. 29F illustrates theresults of the filtering operation for price level 3. The seating mapemphasizes, via color, graphics, and/or icons, the seats that correspondto price level 3, and the event data only displays data corresponding toprice level 3, and does not display data for other price levels.

Optionally, filtering criteria may be combined using Boolean functions(e.g., AND, OR, Exclusive OR, NOT, and/or other Boolean functions).

FIG. 29G illustrates an example user interface via which a user canselect specific seats via a seat map and edit attributes associated withthe selected seats on-the-fly. For example, a user can click on orotherwise select one or more individual seats or a group of seats. Thenumber of seats selected is displayed via the seat count field in thedialog box. The user may change the price level associated with theselected seats (e.g., via the action menu) and/or change the face valueassociated with the tickets for the selected seats. By way of furtherexample, the user may change the status of the selected seats (e.g.,among “open,” “hold,” “kill,” “sold,” etc.). The changes may bereflected in the change list area (e.g., as a result of calculationsbased at least in part on the changes). For example, the change listarea may list the action (e.g., change price level, change seat status),target (e.g., seat identifier, price level, status), the seat count, theimpact, status of change, delete, etc. The changes may be stored inmemory. Thus, the user can specify certain changes, see the effect onthe event data, and then decide to accept/implement the change, orreject/delete the change. The acceptance or rejection of the changes maybe stored in memory in association with the specified changes. Thechanges may be performed and implemented prior to placing tickets onsale for the event and/or after ticket sales have begun. Thus, the userinterface may be used to dynamically change pricing, seat availability,etc., for an on-sale event.

In certain embodiments, the user interface enables the user to selectone or more seats and assign the selected seats to a specificaccount/user prior to or after other tickets are put on sale to thepublic. For example, in certain instances a performer may instruct thattickets for certain seats are to be assigned to the user's mother orfather, without the specified seat tickets ever being put on sale.

The management of seat tickets for a given event may be divided up amongdifferent entities, wherein different entities manage different subsetsof seat tickets for an event. For example, in certain embodiments, theuser interface enables the user to select one or more seats (e.g., asubset, but not all of the venue seats) and assign control/management ofthe selected seats (which may be initially assigned the status of “hold”seats) to a specified authorized entity, wherein the specifiedauthorized entity does not control or manage tickets for other eventseats. For example, in certain instances a governmental entity/city mayown a venue, but may lease it to an operator, which still maintainingcontrol over a relatively small subset of seats (e.g., 200 out of 18,000seats) in order to decide how to allocate the seats (e.g., to visitingdignitaries, honorees, etc.). The governmental entity (or other party)and the venue operator may negotiate which sub-set of seats are to becontrolled by the governmental entity, and the agreement may beimplemented by an operator selecting seats and allocating management ofthe selected seats to the governmental entity (or other specifiedparty). By way of further example, in certain jurisdictions, whilemultiple ticketing service providers may have the right to sell ticketsfor events at a given venue, the multiple ticketing service providersmay divide up the venue seats, wherein a given ticketing serviceprovider is allocated a certain subset of seat tickets to sell. Theseating map may be used to allocate management of/authority to selltickets for respective subsets of venue seats to different ticketingservice providers.

The seat map may be used to assign event alerts and/or time alarms toindividual seats and/or sets of seats. The event alerts may relate to achange in seat status (e.g., from open to sold, from hold to open, fromkilled to open, from open to killed, etc.). The event alert may be tiedto a time criteria, wherein an alert is only provided if a specifiedevent occurs (or does not occur) by a specified date/time.

For example, certain embodiments enable a user to assign an alert to oneor more selected seats, wherein if a ticket for a seat associated withan alert is sold, an alert is transmitted to one or more specifiedrecipients. By way of further example, certain embodiments enable a userto assign an alert to one or more selected seats, wherein if a ticketfor a seat associated with an alert is not sold by a user-specified date(which may be a specified month/day/year, or wherein the date may bespecified relative to the date of the event or initial offer for sale,such as 15 days before the event or 30 days after the seat ticket isoffered for sale) and/or time, an alert (e.g., in the form of an email,SMS message, MMS message, automated voice call, applicationnotification, or otherwise) is transmitted to one or more specifiedrecipients. The seats may be selected for alerts as the sale of seattickets for such seats indicate the overall performance of the ticketsales for the event. For example, the sale of tickets for certain seatsmay indicate that event sales are going well/satisfactorily, while thefailure of such seats to sell by a certain date/time may indicate thatsales are slower than desired. The seat alerts may indicate to therecipients that ticket prices should be raised or lowered in order toenhance revenues.

Further calendar entries, alerts/warning timers (e.g., with associatedexpiration times or calendared dates/times) may be assigned to one ormore seats (e.g., a warning that certain seats initially allocated togovernmental entity will be re-allocated back to the box office whichwill have to sell them). A text message may be displayed by the systemin association with the alert, the text message optionally identifyingone or more seats associated with the alert and/or a message previouslyspecified by a user (e.g., a text and/or graphic message including areminder related to the seats, such as “Seats A-C will be reallocated tothe box office today”). The user may specify one or more recipientsand/or device/email addresses that are to receive the alert andassociated message.

FIG. 29H illustrates an example user interface providing anothermechanism via which a user can edit/change seat attributes (e.g., toenable dynamic pricing of seat tickets). In this example, a menu isprovided via which the user can edit/change the previously set facevalue of seats in a selected price level (e.g., without moving changingthe price level to which the seats are assigned). In addition, fieldsare provided via which the user can edit/change ticket-related fees(e.g., service fee, facility charge, etc.); impact per seat (wherein theuser can enter a delta change in the face value price, or wherein thechange is price/impact is calculated and displayed based on theuser-specified change in the face value field); impact on event gross(the delta/change in expected event gross), etc. The changes may bereflected in the change list area, which lists the action (e.g., changeprice level, change seat status), target (e.g., seat identifier, pricelevel, status), the seat count, the impact, status of change, delete.The changes may be stored in memory.

Thus, the user can specify certain event changes, see the effect on theevent data and reports, and then decide to accept/implement the change,or reject/delete the change. The acceptance or rejection of the changesmay be stored in memory. The changes may be performed prior to placingtickets on sale for the event and/or after ticket sales have begun.

While the user interface illustrated in FIG. 29G enables the user tospecify changes for user-selected specific seats, the user interface ofFIG. 29H lets the user specify change more ambiguously (e.g., via thepop-up dialog box or the event data grid). For example, the user canspecify that 25 seats should be moved from one price level to another,without specifying specific seats that are to be moved to a differentprice level. The system can then calculate the effect on the event data.By way of further example, the user can specify a desired goal (e.g., anincrease of $10,000 in gross revenues), and the system will calculatehow many seats would have to be moved from a first price level to asecond price level (higher than the first price level) in order toachieve the goal. The user may specify any of the event entries as agoal, and the system may calculate one or more ways to achieve the goalby varying one or more parameters, which may be displayed to the user.

An example event setup workflow will now be described. Many entities andpeople having different roles (e.g., advisor, decision maker, executor,etc.) and responsibilities may be involved in an event setup (e.g., indefining the physical layout of the event, the price structure of theevent, in determining the number of held or killed seats, etc.). Forexample, there may be one or more performers (e.g., musicalperformer(s), team(s), actor(s), etc.), promoters, venue operators, boxoffice managers, advisors, dynamic pricing generators, assistantmanagers, etc., involved in setting up a ticketed event. Certainembodiments described herein enable various entities to perform theirroles with corresponding rights and abilities to perform setups,modifications, view data, etc.

As discussed above, different users may have different roles. Forexample, certain users may act as advisors with respect to an eventsetup. Such advisors may be granted access to view event data, such asthat described herein, specify provisional changes (e.g., in ticketprices, the number of price levels, seat statuses, etc., via a changelist or otherwise), view the calculated results of such changes prior tothe changes being actually implemented, save the changes as one or moreproposed event record change files, and/or designate a change file as a“recommended change” file. The advisor may also recommend what types oftickets should be issued for which seats (e.g., a physical ticket, anelectronic ticket, and/or a virtual ticket). Thus, the advisor may makeproposals with respect to changes to an event setup, but does not havethe authority to actually instruct that the changes be implemented as anon-sale event. Thus, an advisor may be enabled to perform what-ifanalyses on various different event setups and provide recommendationson how the event should be setup to a decision maker (e.g., an eventpromoter) that has the authority to approve such changes, but withoutsuch approval, the event is not setup based on the advisor'srecommendations or saved change files.

The decision maker may view the proposal file(s) and then approvedisapprove such changes and/or may make further changes, wherein suchapproval, disapproval, and/or further changes are stored in memory. Thedecision maker automatically may be informed of a new or revisedproposal from an advisor via an email, an electronic file notation, analert displayed via one or more of the user interfaces described herein,or otherwise. For example, an advisor may activate a control instructingthe system to transmit a proposal to a decision maker, and the systemmay provide the decision maker with the proposal, which may include oneor more of the user interfaces discussed herein.

After viewing a proposal, the decision maker may then instruct anexecutor (e.g., a box office) to implement the changes (e.g., the changelist defined by the advisor, as approved and/or modified by the decisionmaker). For example, the instructions may be provided via an email, anelectronic file notation, an alert displayed via one or more of the userinterfaces described herein, or otherwise. The executor may thenimplement the specified changes (e.g., using one or more of the userinterfaces described herein), and the event will be setup accordingly(e.g., with the specified price levels, seat-to-price level assignments,ticket face values, discounts, and/or seat statuses, etc.). The executormay be provided with a certain degree of discretion in implementingchanges. For example, the decision maker may instruct the executor tomove 25 seats from price level 1 to price level 2, without specifyingwhich of the seats in price level 1 are to be moved. The executor mayselect which 25 seats are to be moved, and then move theexecutor-selected seats from price level 1 to price level 2 accordingly.The decision maker may be automatically information by the system whenthe executor has implemented a change (e.g., where the system detectsthat the user has instructed the system to implement the change, andtransmits an electronic notification to the appropriate recipients). Thetickets may then be offered for sale to purchasers in accordance withthe implemented event setup.

By way of further example, as similarly discussed above, certainusers/entities may be provided with the authorization to control ticketsand other setup properties for a subset of event seats, but not for allevent seats.

The allocation of authority to perform and execute various tasks may beperformed by a user that has the authority to assign roles and providescorresponding authority to users to execute those roles, optionally onan event-by-event basis. The foregoing tasks may be performed using oneor more user interfaces provided via the ticket system or otherwise. Thespecified allocation of authority may be stored in memory in respectiveuser and/or event records or otherwise.

For example, a given user may be provided with a userID and/or passwordto access the system, and the system may use the userID and/or passwordto identify the user logging in, access a user and/or event record todetermine the user's rights to access certain event data, to createevent models, and to implement event changes, and provide the user withcorresponding authorized functionality. Of course, other techniques maybe used to validate a user and enable the user to login, such asbiometrics (e.g., fingerprints), smart identification cards, dongles,etc.

Optionally a given user assigned a corresponding role may be providedwith the authority to designate another user or users as having asub-authority to perform some or all of the tasks the delegating userhas the authority to perform. For example, a box office manager maycreate a tree of authority, where the box office manager may authorizean assistant box office manager to make and/or implement certain typesof changes (e.g., change the status of a seat from held to open), butnot others (e.g., the ability to change ticket face values). By way offurther example, a decision maker, such as promoter, can delegatedecision making authority to other designated users.

Optionally, a given user can instruct the ticket system to enablesomeone to whom the user has provided such sub-authority to furthergrant sub-authority to still another user. Optionally, a given user caninstruct the ticket system not to permit someone to whom the user hasprovided such sub-authority to further grant sub-authority to stillanother user. The system may then provide the user granted sub-authoritywith the specified degree of rights to view data, experiment withchanges, and/or implement changes.

In certain embodiments, the system may keep records of each proposaland/or implemented change lists and may generate a report thereof withan associated timeline. The report may note who proposed a given change(e.g., change in price level, price break, face price, seat status,),who approved the given change, who implemented the given change, whenthe foregoing tasks were performed, and what the changes were. Thechanges may be shown graphical and/or textually (e.g., beginning with abase event, and subsequent changes). In addition, the history of salesactivity may be provided showing which seat tickets were sold when,changes in ticket sales rates, changes in the absolute number and/orpercent of seat tickets sold, etc.

The history may be presented statically, such as using various screenshots, textual tables, graphs, or otherwise in a physical or electronicreport. By way of further example, the history may be provided in adynamic format. By way of illustration, the history may be replayed as amovie (e.g., a time elapsed movie where the user can control the speedof the history playback), with the seat map being sequentiallyre-colored to reflect the changes in the order made, and the textlikewise being continuously updated to reflect the changes. The user mayspecify start and stop points for the playback by specifying start andstop dates/times or events (e.g., beginning when a first change inticket pricing occurred and ending just before a second change is ticketpricing occurred; or beginning when a first specified percentage ornumber of seat tickets were sold, and ending when a second specifiedpercentage or number of seat tickets were sold) to thereby more quicklyfocus on areas of interest.

FIG. 30 illustrates an example event setup process which may be executedby the ticket system and/or other system. At state 3002, entitiesinvolved in setting up an event (e.g., a performer manager, promoter,venue operator, etc.) negotiate regarding the characteristics of thesetup for a new event. At state 3004, an agreed upon physicalstage/event configuration is specified (e.g., end stage, 360 degreestage), and the configuration may be stored in a record associated withthe event. At state 3006, a high level authorized user (e.g., thehighest level executor, such as the box office manager) selects atemplate/venue layout from a menu of templates stored memory matchingthe specified physical configuration and creates a base event. Thebased-event may be stored in the event record. At state 3008, the highlevel authorized user/executor designates other users (e.g., box officestaff) as executors, and designates another user, such as the promoter,as the highest level decision maker for the event and optionally forother events. The designations may be stored in the event record. Thedecision maker is provided the authority to designate other decisionmakers and advisors. At state 3010, one or more of the users model eventincome using the interfaces discussed herein (e.g., by experimentingwith different numbers of seats at each price level and different baseprices at each price level). At state 3012, the appropriate user selectseats via a seat map or otherwise, and assigns them appropriate priceslevels and set base prices. At state 3014, the foregoing changes may berecorded in change lists in the event record, which may displayed to auser.

At state 3016, once the decision maker approves the changes (wherein theapproval may be stored in the event record), the decision makerinstructs the executors to make the actual changes to the event (e.g.,via an electronic communication transmitted by the system). At state3018, the event is put on sale in accordance with the event setup (e.g.,with tickets offered at the designated prices, using the designatedevent layout, with held and killed seats not being offered for sale),and the system may process ticket orders and deliver tickets (e.g.,physical, electronic, and/or virtual tickets). At state 3020, the systemdisplays the sales activity graphically (e.g., via seat maps, graphs,etc.) and textually (e.g. via the report and/or event data areasdiscussed above), optionally in substantially real-time. Users may setupon or more filters to select what is displayed and reported. At state3022, based on the sales activity of the active event and/or otherfactors, users may generate additional changes reflected incorresponding change lists which executors can post to the ticket systemduring live sales.

Interactive seat maps will now be discussed in relation to exampleembodiments illustrated in the figures. As illustrated in FIGS. 20 and21A-21Z, interactive seat maps of a venue and/or event may be providedfor display on networked user terminals (e.g., phones, personalcomputers, interactive televisions, or networked devices, etc.) ofpotential ticket purchasers.

A system, such as the ticket system discussed above, may access datafrom a database (such as one or more databases storing venue maps,seating maps and data, pricing data, event data, user account andpreference information, social network information, photograph tagginginformation, event invitation and replies, other data displayed via theuser interfaces described herein, and/or other data) and use such datato populate the user interfaces, including the interactive seat maps.The populated data may be dynamically changed in response to a user'sactions (e.g., in response to some or all of the following: usersearches, specified preferences, navigation instructions, seatselections, section selections, ticket purchase instructions, tagginginstructions, control activations, etc.). The user interfaces, includingthe interactive seat maps, may be updated in substantially real-time inresponse to user actions and/or in response to updated data, such asupdates in ticket pricing, seat availability, seat status, etc., as madeor detected by the system.

In addition, in certain embodiments, the system will provide for displayinformation as to the distance from the seat to seats of the user'sfriends who have tickets at the event (e.g., expressed as a number ofseats, rows, sections, and/or in a unit of length, such as feet, meters,or yards).

A given seat may have different types of tickets available (e.g., adult,child, etc.). In certain instances, different ticket types for a givenseat may be associated with different prices. Optionally, if there isonly one seat type available (e.g. only “adult” or only “child”), andthe user clicks on the seat to add the seat to the user's shopping cartor list of selected seats, the seat will be added immediately. However,if there are multiple seat types available, a user interface may bepresented (e.g., via a pop-up dialog box), asking the user to choose thetype of seat the user wants to purchase before the seat is added to theuser's selected seats. A link may be provided in association with theadditional information via which still further additional informationmay be provided.

The interactive seat maps may be configured to facilitate userunderstanding with respect to an event of the available seats, prices,available discounts, seating packages, other seat characteristics, whichof their friends are attending and where they are sitting, etc., by, incertain embodiments, providing a coherent and/or unified view (includinga graphical representation) of what may be a complex set of prices andpromotions, and other seat and event related information. Further,certain embodiments may enable a user to select a seat or section, andhave a photograph, video, or other representation (in two and/or threedimensions) of the view from that seat or section displayed to the user.

As illustrated in FIG. 20, the user interface may include a navigationmap, and in another area, may include an expanded view of a section ofthe venue that indicates seats selected by the user, seats purchased bythe user, seats that match user search criteria (e.g., price range,seating section(s), seat type, special offer(s) specified by the user,etc.), other seats that are available, seats that are not available.

Controls are provided via which the user can navigate around the mapand/or zoom into a certain section of the map. For example, the map isconfigured to enable a user to click on an area of a map and drag themap to change the displayed map area. In certain embodiments, even whena user clicks or otherwise selects a particular seating area or section,to thereby expand the view of the selected area, the entire venue isstill displayed in an area of the map, with the seat statuses indicated(e.g., via color and/or text). For example, if a user enters searchcriteria (e.g., seats having a ticket price between $50-$100), the userinterface will highlight (e.g., via color coding or otherwise) the seatsand/or sections that match the search criteria. If the user then selectsa given highlighted section, the user interface will zoom in on theselected section, while still displaying an overall view of the venue(which may be reduced in size) in a corner or elsewhere, where theoverall view still highlights the seats/sections matching the user'ssearch criteria (e.g., seats between $50-$100).

Optionally, if the user hovers a pointer (e.g., a cursor) over a certainseat or seating area, or otherwise indicates a seat or seating section(e.g., by clicking on a specific seat or seating area), additionalinformation is provided (e.g., via a pop-up window or overlay) regardingthe corresponding seat or seating section. For example, the additionalinformation may include an indication as to whether an offer code isneeded, and if so, from which source, the specific seating information(e.g., section, row number, seat number, the ticket price, the type ofticket (e.g., adult-full price, adult-discounted, child, etc.) etc.), anindication as to whether the seating area only has single seatsavailable (and not two or more available adjacent seats). Otherinformation, such as whether the seat is in a covered area or an exposedarea, in the shade or in direct sunlight, the distance of the seat to anexit, bathroom, concessions, parking lot, and/or other destination, howfar the seat is from an aisle (e.g., expressed as a number of seatsand/or in a unit of length, such as feet, meters, or yards), expectedtemperature at the seat during the event, whether there is waiterservice to the seat, and/or other information may be displayed as well.

As illustrated in FIG. 21A, the user interface may include a map thatgraphically (e.g., via a drawing or a photograph) represents a seatingchart of the entire venue (optionally with various sections identifiedgraphically, via color coding, and/or via alphanumeric text), and anexpanded view of the venue showing individual seats, wherein the usercan move a navigation box over the seating chart of the entire venue toselect the area that should be shown in the expanded view. Optionally,corresponding colors are used to indicate seat status with respect toavailability (e.g., available, sold, on hold, etc.), but not to indicateprice, which may be shown textually. Optionally instead, correspondingcolors are used to indicate seat ticket price.

As illustrated in FIG. 21B, the user interface may include a map in aone area that graphically depicts a seating chart of the entire venuefor navigation purposes (optionally with various sections identifiedgraphically, via color coding, and/or via alphanumeric text), and inanother area, depicts an expanded view of certain of the seatingsections showing the certain sections in greater detail, but optionallywithout showing individual seats. As similarly discussed above, the usercan move a navigation box over the seating chart of the entire venue toselect the area that should be shown in the expanded view.

In an example embodiment, such as that illustrated in FIG. 21B, when themap is zoomed out, displaying the venue map in a main area of the userinterface, sections of the venue may be color coded (e.g., gray, lightblue, medium blue, and/or dark blue). For example, gray (or other color)may be used to indicate that a section is either completely sold out ordoes not contain any seats that match the user's selected price rangeand/or ticket options. Blue (or other color) may be used to indicatethat there are at least some seats within the section that match theuser's selected price range and/or ticket options. Variations of a color(e.g., the darkness or intensity) may be used to provide additionalinformation. For example, the darker the blue, the more seats within thesection that match the user's search criteria.

Depending on the size of the venue, the number of venue seats, and/orthe size and/or resolution of the user's display, the interactive mapmay optionally display all of the seats in a venue at the same time, asillustrated in FIG. 21C.

Other information may be stored in the system database and included inthe interactive map. By way of example and not limitation, seat shape,seat type (e.g., cushioned, non-cushioned, back rest, no back rest,etc.), and/or seat rotation angle may be included and displayed.Information may be conveyed via a seat icon (or other indicator) using acorresponding interior color, outline color, interiorsymbol/text/character, color of such symbol, one or more orbitingsymbols that are optionally color coded, etc.

In certain embodiments, the software application used to configure theinteractive seat map intended for display to consumer for the purchaseof event tickets is optionally the same or substantially the samesoftware application used for event creation. In certain embodiments,the shading, coding, and behavior of the user interface is controlled bya scripting language which is passed to the map allowing the behavior tobe changed dynamically. For example, the scripting language may be usedto control polygon rendering for the map (e.g., which may be used toindicate seating areas), seat rendering, hover-over message handling,and user interface control.

The example highly configurable map can be configured as desired. Forexample, the map can be configured to display a timed entry in a formsimilar to that of a calendar entry (e.g., a Microsoft Outlook calendaror Google calendar entry).

The map may be configured provide “view from the seat” images (e.g.,movies, photographs, graphic renderings, etc.). For example, a user mayselect/click-on a seat/section and/or an associated icon (e.g., a camerasymbol), and the view from the seat or section may be displayed. Theimage(s) may include one or more static images, a view from the seat, aview to the seat from the performance area, and/or an immersive virtualreality 360 degree or full sphere view.

Certain embodiments of the map are configured to display dynamicsub-content. For example, the image of the venue may be modified todisplay ads selected based on user characteristics (e.g., the user'slocation, the subject matter the user is viewing, etc.) on the mapitself (e.g., on a playing field, stage, scoreboard, billboard, etc.).By way of illustration, the content may be a static advertisementincluding a static image and/or text, or a movie. The advertisements maybe selected and/or served via an advertisement server operated by theoperator of the ticket system, an advertisement trafficker, orotherwise.

Optionally, the map may be hierarchical and may embed hyperlinks. Forexample, the map may display a campus view, illustrating severalbuildings at the same time from a bird's eye or oblique view. If it isdetected that the user is selecting (e.g., via a hover or click-onoperation) a building including a venue used for ticketed events (e.g.,an auditorium or sports arena), the map user interface may respond byaccessing and displaying a corresponding seating map for the ticketedvenue within the selected building.

By way of further example and as illustrated in FIGS. 21A and 21C, withrespect to seat colors, dark blue (or other color) may be used toindicate that the seat is available for purchase and matches the user'sselected price range and ticket options. Light blue (or other color) maybe used to indicate that the seat is available for purchase, but isoutside the user's selected price range and/or ticket options. Gray (orother color) may be used to indicate that the seat is not available forpurchase. Orange (or other color) may be used to indicate that thecursor is over that seat or the user has already added the seat to theuser's selected seats.

Optionally, in addition or instead of coloring coding, if the map isbeing viewed via a 3D terminal (e.g., a terminal that requires glassesto view the image in 3D (sometimes referred to as “active 3D”), or aterminal that does not require glasses to view the image in 3D), theamount of 3D effect may be used to provide information. For example, thecloser the match with a user's search criteria, the more the 3D effectmay be emphasized. By way of illustration, a matching section or seatmay appear to project from the image in an amount corresponding to thedegree of match.

As illustrated in FIG. 21D, changes to the interactive seat map mayoptionally be updated in substantially real-time (e.g., in 2 minutes orless). For example, changes in seat availability, seat prices, sourcesof seat tickets, seat status, and/or other seat and event relatedinformation discussed herein, and so on, may be updated in substantiallyreal-time.

FIG. 21E illustrates an example user interface including an interactiveseat map for an event. As similarly discussed above, if the user pointsat/hovers a cursor over a seat, additional information regarding theseat is presented (e.g., seat location information, an indication as towhether the seat is in the shade, ticket price, service fees, taxes,total cost, etc.). In addition, controls are provided via which a usercan recommend the event to others. If the user activates the recommendcontrol, the recommendation may be displayed on the user's socialnetwork page, the social network page of the user's friends, and/ornotifications regarding the recommendation may be transmitted to theuser's friends (e.g., via email, SMS, MMS, or otherwise). FIG. 21Fillustrates an example user interface similar to that of FIG. 21E. Inthis example, if the user points at/hovers a cursor over a seat,additional information regarding the seat is presented (e.g., seatlocation information, an indication as to whether alcohol is permittedat that seat, an indication as to whether the view is a full view, apartially blocked via, a total blocked view, etc.).

FIG. 21G illustrates an example user interface including an interactiveseat map and an offer menu where the user can select one or more offersrelated to seat tickets (and which may be restricted to specific seatsor specific groups of seats) and/or seat classifications (e.g., fullprice, children under 12) and the interactive seat map which highlightsseats and/or seating areas corresponding to those offers. If the userpoints at or hovers over a corresponding seating area or over the offer,additional details regarding the offer may be presented. By way ofexample, the offers may be sponsored by one or morecompanies/advertisers and may offer ticket discounts, provide access topurchase seats not available to the general public, or provide anancillary item (e.g., food, clothing, parking, travel) at a discount orfor free with the purchase of seat ticket.

Additionally, certain embodiments will display warnings or otherinformation in certain situations that the user needs to acknowledgeviewing before being allowed to purchase a ticket via the map. Forexample, as illustrated in FIG. 21H, if a user hovers a cursor over orclicks on a seat that has an obstructed view, a warning regarding theobstructed view may be provided for display via a pop-up window orotherwise, and the warning may have an associated control (e.g., a“continue” or “agree” control) that the user needs to activate beforethe system or user interface will allow the user to add the seat to theuser's seat ticket list and/or before the user is enabled to purchase aticket for the seat.

Optionally, as illustrated in FIG. 21I, the system or user interfacedetects if the user's seat selection of one or more seats would leave a“stranded” seat in row (a single available seat, rather than two or moreadjacent available seats), where if the user selected a different set,but the same number, of adjacent seats in the row, there would not be astranded seat, or there would be fewer stranded seats (e.g., onestranded seat instead of two stranded seats). If such a situationoccurs, a notification regarding the foregoing may be provided to theuser and the notification may inform the user that the user is requiredto or is asked to select a different set of seats so as to avoid ormitigate the occurrence of stranded seats, as illustrated in FIG. 21J.The notification may specify or suggest one or more comparable sets ofseats that would eliminate or mitigate the number of stranded seats. Theuser may be asked to or required to activate a control acknowledging thenotification. Optionally, if the user does not select a different set ofseats and/or does not acknowledge the notification, the user may beprevented from proceeding with adding the tickets to the user's selectedtickets and/or is prevented from purchasing the tickets. Optionally,instead, the user may be enabled to continue with the seat selection orpurchase, even if a stranded seat results.

By way of further example, as illustrated in FIG. 21K, the system oruser interface may detect if the user has selected a set of seats (e.g.,two or more seats), where two seats are separated by an aisle or barrier(e.g., a pole). The user interface may provide a warning regarding theseat separation. The warning may have an associated control (e.g., a“continue” or “agree” control) that the user needs to activate beforethe system or user interface will allow the user to add the seat to theuser's seat ticket list and/or before the user is enabled to purchase aticket for the seat.

Optionally, as illustrated in FIG. 21K, a user's seat selection isdisplayed on the same user interface as the map (e.g., directly belowthe map). Optionally, a control is provided (e.g., a “Show Details”control) to display additional details regarding the selected seats(e.g., price, seat section, row, number, ticket type, total cost),wherein the user can modify the ticket list. The user can then continuebrowsing the map, or click a “Checkout” control to complete thepurchase. Optionally, the selected seats are not reserved until theCheckout control is activated (at which point the tickets may bereserved for a certain period of time). Optionally, if the user does notcomplete the checkout process within a certain period of time, thecheckout process is terminated, and the tickets are no longer designatedas reserved (although optionally they may still be in listed in the listof user selected seats), thereby enabling other users to purchase thetickets.

Thus, for example, the user interface may report on the number of seatsselected by the user and the subtotal cost (e.g., the total of the facevalue of the selected tickets, optionally with any discount applied,optionally without any discount applied). Optionally, the total cost,including any discounts, handling fees, venue fees, taxes, and/orshipping is displayed.

As similarly discussed elsewhere herein, in the illustrated example, afield is provided via which the user may enter an offer code orpassword. Fields and/or a slide bar are provided via which the user canset lower and/or upper bounds for tickets prices the user is interestedin. Optionally, if the system determines that an event has only onestandard admission price, the system will not offer a slider or otheruser interface for specifying pricing as a search criteria. A field isprovided via which the user can instruct the system to highlight and/oronly display seats that are part of a special offer (e.g., a presale fora credit card holder of a certain company, or a fan club presale).

In certain embodiments, as illustrated in FIG. 21L, a user interface maybe provided that enables a user to purchase or reserve a right (whichmay be represented by a physical or electronic ticket) to enter a venue(such as a museum or amusement park ride) at a certain time or to use afacility at a certain time (e.g., a golf course tee time). The userinterface may list a plurality of time slots, with an associated “add”control. If the user activates an add control, the associated time slotis added to the user's list of selected time slots or, in certainembodiments, directly to the user's shopping card. If the user points ator hovers a cursor over a particular time listing, additional relatedinformation may be displayed (e.g., via a pop-up or otherwise). Forexample, the additional information may be an entry time, a price orprice range, number of remaining tickets for the corresponding timeslot.

As illustrated in FIG. 21M, upon detection the a user is hovering acursor over or has selected a seat that require a special offer code(e.g., from a specific credit card company, from a fan club, etc.), anotice may be presented via the user interface, listing a source of theoffer code, a seat location/identifier, a ticket price and associatedfees. as illustrated in FIG. 21N, the user interface may indicate, viaicons or otherwise, seats that are handicapped accessible.

By way of further example, if no tickets are available in a given saleschannel (an initial or primary sales channel) in a section pointed at orclicked on by the user, a notification may be provided as to theavailability of tickets in the section via one or more alternatechannels (e.g., a resale/secondary market channel, an auction channel,etc.) as illustrated in FIG. 21O. The notification may include a link toa purchase page or other user interface of the alternate channel(s).

FIGS. 21R-21U illustrate interactive seat maps enabling users topurchase tickets via an auction format and/or via where a user makes anoffer at a user-specified price, which may or may not be accepted by theticket seller (e.g., a primary market ticket seller making the initialticket sale). Via the illustrated interactive seat maps, users areprovided the flexibility to make an offer in different seating areas,enter different prices for different seating areas, tie an offer for oneor more tickets together with their friend's offers, and set therelative priority rank of the user's preference. By way of furtherillustration, if the user makes an offer, the offer may be automaticallyevaluated by the ticket system, which may compare the user's offer witha specified minimum acceptable offer of the ticket seller. If the offermeets or exceeds the specified minimum acceptable offer, the offer maybe automatically accepted, the user may be informed of the acceptance,the user may be charged for the ticket at the offer price (and anyrelated service charges), the user payment (or an agreed upon portionthereof) may be transferred to the ticket seller, and the ticket may bedelivered to the user. If the offer fails to meet the specified minimumacceptable offer, the offer may be automatically denied, and the usermay be informed of the denial and optionally of the minimum acceptableoffer price, and the user may have the option to provide another offer.Optionally, rather than having an offer automatically accepted ordenied, the offer may be communicated to an authorized human operatorwho may manually inform the system whether the offer is accepted ordenied, and the system may then process the acceptance or denial assimilarly discussed above. The minimum acceptable offer may be a setamount or may be varied according to a formula which takes into accountthe number of seat tickets left unsold in a given seat area, the numberof unsold seats for the event overall, and/or the number of days untilthe event is to take place.

If an auction format is used, the system may specify a minimum bid priceand/or a minimum bid increment. Users may then submit bids, which arereceived by the system. The system may determine the highest bidder fora given ticket, and the highest ticket may then be awarded and deliveredto the highest bidder. The winning user may be charged for the ticket atthe winning bid amount and the user payment (or an agreed upon portionthereof) may be transferred to the ticket seller.

If the user submitted multiple relative priority order, once the user isawarded tickets through one of the user's relative priority offers, thenthe rest of the relative priority offers/seating areas the user made anoffer on may be ignored and/or removed from a ticket request data storeso that the user only wins one set of tickets. When determining whichuser wins which ticket, the relative priority rank the user indicatesfor the associated seating area will also be taken into consideration.

In certain embodiments, the auction may be a ranked seat auction, wherethere can be multiple winners within the same auction. By way ofillustration, in certain auctions, a user does not bid for tickets to aparticular seat. Instead, the user may be simply bidding for tickets tosee the event in a seat that will later be determined by comparing theuser's bid with other bids that are submitted before the auction ends.The seat tickets within an auction may have been ranked according towhat the event providers or the ticket seller have determined to be fromgreater to lesser desirability and matching it against bids submitted byusers optionally while taking into consideration the relative priorityrank users associate with the different seating areas. At the end of theauction, tickets may be assigned to winning bidders based on thoserankings so that those winning bidders who bid higher than the user areassigned higher ranked seats and those winning bidders who bid lowerthan the user will be assigned lower ranked seats, with ties optionallybroken in favor of those who submit their final bid earlier than otherbids.

Optionally, tickets different seats may be made available for purchaseusing different techniques. For example, some seat tickets may beavailable at a preset price (e.g., wherein the user simply agrees topurchase the ticket at the preset price and the purchase isautomatically processed by the system), some seat ticket may beavailable via an auction, some tickets may be available where a usermakes a purchase offer at a specified price which the current ticketholder may accept or refuse or reply to with a counter-offer. Some seatsmay be made available using two or techniques. For example, a ticketsfor a seat may be available at a set price, wherein if a user pays theset price, the purchase will be completed, or the user may make an offerfor the set at less than the set price, where the ticket owner mayaccept or decline the user's offer, and the purchase will not becompleted unless the ticket owner accepts the user's offer. Theinteractive seat map may include coding (e.g., color, icon, and/or textcoding), which indicates the purchasing technique for a given seat, sothat a user can decide not just what seats they wish to acquire ticketsfor, but can also decide what purchase technique is acceptable to theuser and make ticket purchase decisions accordingly.

FIG. 21R illustrates an example interactive seat map listing the numberof event tickets available, a specified minimum offer price, an averageoffer amount corresponding to offers may for event tickets, and thenumber of event ticket offers received. The user may also activate acontrol to have the seat map indicate where a user's friends have madeoffers. Via the interactive seat map, the user may choose a section,level, row, and/or seat, enter an offer price, and activate a submitcontrol. The offer may then be processed as similarly discussed above.

FIG. 21S illustrates an example interactive seat map, similar to that ofFIG. 21R, wherein a level (level 100) has been selected by the user. Apop-up window is displayed providing addition information regarding theselected level (e.g., the distance from the floor, the number of ticketsavailable for the selected level, the number of offers made for theselected level).

As illustrated in FIG. 21T, a chat user interface may be providedenabling a user to textually and/or via voice chat in substantiallyreal-time with other users/friends regarding which seats to make anoffer on, how much to offer for the seats, sitting together, etc. Theselections may then be listed on the user interface, as illustrated inFIG. 21U. A priority field may be provided, once the auction or offerperiod ends, the first highest priority offer will be considered firstby the system before the second highest priority offer is considered bythe system, and so on, until one of the offers is accepted or untilthere are no more selections of the user. Optionally, users can tietheir ticket offer to that of their friends. As illustrated in FIG. 21U,for individual offer line items, the “seat me with” user interfaceenables the user to select from a list of the user's social networkingsite friends (e.g., with the user's friends identified as similarlydescribed elsewhere herein) which friend(s) the user wants that specificoffer line item to be tied together with. The system determines if boththe user's offer and that of the user's selected friends' are accepted.In such instance, the system will not award the user the ticket (theuser's offer will not be accepted) unless the selected friend(s)offer(s) are also accepted for that same seating location.

An example embodiment provides user interfaces, illustrated in FIGS.21V-21W, that enable a user to make an offer to purchase a ticket fromanother user that had previously purchased the ticket. For example, theuser interface may include a venue map, such as the map illustrated inFIG. 21V. The user may select a section or specific seats for which theuser wants purchase tickets that may be held or owned by other users. Ifa determination is made that a ticket holder is willing to accept orentertain ticket purchase offers from other users (e.g., based on anindication provided by the ticket holder to the system via a userinterface, wherein the indication is associated with the correspondingseat, where the ticket holder may also specify a minimum price which maylikewise be stored), the system may cause the ticket holder's seat iconto include a corresponding indication (e.g., a corresponding icon,border, color, etc.). The system may transmit the offer in an offernotification (e.g., via email, SMS message, MMS message, voice message,seat map, web page, phone app, or otherwise), including a price,submitted by the user to the ticket holder via a purchase offerinterface, which may include a field to receive a user specified offerprice. The system may receive an acceptance or refusal of the offer fromthe ticket holder (e.g., wherein the ticket holder activates an accesscontrol or refusal control including in the notification or via a pageaccessed by clicking on a link or other control including in the offernotification), and transmit an indication of such acceptance or refusalto the user (e.g., via email, SMS message, MMS message, voice message,seat map, web page, phone app, or otherwise). If the ticket holderaccepts the offer, the system may store an indication corresponding tothe acceptance, process the purchase (e.g., charge the user's creditcard or other financial instrument, and charge the user and/or ticketholder a service fee), and transfer the ticket (which may be a physicalor electronic ticket) to the user. The system may store an indication ina ticket database that the ticket has been transferred to the user inassociation with a record for the corresponding seat. The system maycancel or otherwise invalidate the original ticket holder's ticket toprevent use thereof (e.g., by recording in memory an indication that theoriginal ticket holder is invalid, so that if it is used and scanned atthe event venue, the admission system will access the ticket databaseand determine that the original ticket is not valid). Optionally, if theticket holder refuses an offer, the ticket holder may submit acounteroffer, which the system may communicate to the user, who in turnmay accept or refuse the counteroffer, and may couple a refusal with acounter-counter offer.

FIG. 21V illustrates an example user interface including controls viawhich a user may make an offer to purchase tickets from other users forone or more seats. In addition, controls are provided which enable theuser to select a seat, and have a photograph, video, or otherrepresentation of the view from that seat or section displayed. Further,the user interface identifies the current ticket holder (e.g., via name,nickname, photograph, or otherwise), of a user selected seat, andprovides indications (in the form of text, color, graphics, etc.) thatindicate whether the current ticket holder is open to receiving ticketpurchase offers, and provides the minimum price the current holderexpects or requires if the ticket holder is to sell the ticket. Inaddition, various search and filtering controls and fields(offer/password entry field, price range controls, ticket option menu,who is sitting where menu, etc.), and event and venue information (e.g.,name of performer, venue name, address, event date/time, userratings/recommendations, number of user communications regarding theevent, who is attending, on-sale dates/times for tickets, etc.) areprovided as similarly discussed above with respect to other example userinterfaces.

In addition, the example user interface displays the average ticketprices (or other statistical calculation) for event tickets sold, ascalculated by the ticket system or other system. For example, the userinterface may display the average price and/or price range for ticketsin a specified period of time, such as the current day. Optionally, theticket sale price information may be provided for a section or otherseating area specified by the user. A control is provided via which theuser can instruct the system to provide historical event ticket saleprices for other time periods (e.g., past days or weeks).

FIG. 21W illustrates the user interface of FIG. 21V with a pricesubmission user interface. The user can enter an offer price per ticketand a day and time until the offer expires. Optionally, the user isinstructed that there is a minimum required price and if the user entersa price below the minimum, the system may so detect, and inform the userthat the offer is not accepted because the offer is below the minimumspecified amount.

FIGS. 21X-21Z illustrate user interfaces, including interactive seatmaps, that provide a unified presentation of event seat tickets in boththe primary market (initial sale of an event ticket) and the secondarymarket (ticket resales from prior purchasers. The information used topopulate the user interface may be obtained from a plurality of systemsassociated with respective primary and secondary ticket sellers. Someticket sellers may be engaged in both the primary and secondary markets,while other ticket sellers may be only primary market ticket sellers oronly secondary market ticket sellers.

As illustrated in FIG. 21X, a user interface is provided via which theuser can select one or more ticket sources, which may include primaryand secondary market sellers. The seat map is then updated to highlightthe seats whose tickets are available from the selected sources. Theseat icons may be coded differently (e.g., different internal graphics,different colors, different borders, etc.) to indicate the source of theticket for a given seat and/or an indication as to whether the source isa primary market source or a secondary market source. The user interfaceincludes various other fields, controls, and information, as similarlydiscussed above with respect to certain other user interfaces.

FIG. 21Y illustrates an example user interface (such as the userinterface illustrated in FIG. 21X) including seats selected by the user.When the user hovers over or points at the selected seats, additionalinformation regarding the seats is presented, including the source ofthe seat ticket and/or an indication as to whether the source is aprimary market or secondary market source.

In certain embodiments, a ticket holder reselling a ticket can specifyto which other users or category of users the ticket holder is willingto resell a ticket to. For example, in some instances, a ticket holdermay not want to sell a ticket to a ticket broker, but is only willing tosell the ticket to someone the ticket holder has designated a friend orthat may be a friend of a friend (or that may be a member of a specifiedgroup, such as a fan group of the performer performing at the event).The ticket holder can also enter, via an electronic form or otherwise, arequested price per ticket and a reason the ticket holder is not usingthe ticket. The ticket system may then determine whether a user seekingto purchase tickets fits the ticket holder specified designation, and ifnot, prevent or inhibit the user from purchasing the ticket. Forexample, the system may indicate that the seat ticket is not availablefor purchase to users that do not fit the ticket holder specifieddesignation.

On the buyer side, a seat map may indicate which seat tickets beingoffered for resale are being offered by a friend of the buyer (which maybe determined from information accessed from a social network database).Further, a buying user may specify that the user wants to filter theseat map to indicate which seats tickets being offered for resale arebeing offered by a friend (or other specified seller-type). FIG. 21Zillustrates such an example user interface. In this example, the userhas selected, under ticket options, “Exclusive from Friends.” The seatmap has been updated to indicate via a star which seats are associatedwith tickets being offered for resale by a friend. If the user hoversthe cursor over such a seat, additional information is presented, suchas the seat location, the reason provided by the user for selling theticket, the requested price, and an indication that the ticket holder isonly selling the ticket to friends. Controls are provided via which theuser can send the ticket holder a message.

In certain embodiments, a ticket may be transferred (e.g., resold),without a ticket seller having to manually send a physical ticket to aticket buyer, For example, ticket holders can electronically transfer aticket to recipient via the ticket system. The ticket holder mayidentify the ticket being sold by selecting the ticket from a menuprovided by the ticket system of tickets held by the ticket holder(e.g., based on the ticket holder's account information) or by providingto the system identifying information relating to the ticket (e.g., aunique code printed on the ticket if the ticket is a physical ticket).When the purchase is complete or when otherwise instructed by the ticketholder, the system can then cancel the ticket held by the ticket holderThe ticket system can keep a record of each transaction so that thesystem can track who the current ticket holder is, as well as who haspreviously held the ticket.

In certain embodiments, the interactive map may disabled if the ticketsystem is so loaded that it cannot adequately support one or moreinstances of the interactive map (e.g., where the system cannot provideupdates regarding which seats are available quickly enough (e.g., insubstantially real time), resulting in seats that have becomeunavailable still being displayed as available) as illustrated in FIG.21P. For example, if consumer activity on a given event spikes (e.g.,during the first hour or other time period event tickets are first puton sale), the system may automatically disable the interactive seat mapand users may instead be presented with or directed to an alternativeticket purchase user interface, such as that illustrated in FIG. 21Q.For example, the alternative user interface may not enable a user toselect specific seats. By way of illustration, the alternative userinterface may instead enable a user to specify a price level or bestavailable seats, where the system, rather than the user, then selectsthe specific open seats that match the user's criteria and rankings orquality assignments with respect to the open seats (e.g., the system maylocate the seats with the highest ranking or quality assignments thatare open and that meet the user's price and/or section selectioncriteria). The system then enables the user to purchase the systemselected seats via the alternative ticket purchase user interface. Anotification may be provided for display to the user regarding thedisablement of the interactive map. Optionally, a notification may firstbe provided indicating that due to detected system loading, theperformance of the interactive map may be significantly degraded (e.g.,very slow), and the user may be offered the option to continue using theinteractive map or to use the alternative user interface. Then, theselected user interface is presented to the user.

By way of example, consumer activity may be measured by one or more ofthe following factors:

a. the amount of web traffic that is arriving on an event's purchasepage;

b. the number of seats that are simultaneously reserved on the ticketingsystem.

additionally, thresholds for these factors may vary depending on theevent lifecycle (e.g. If an on-sale is coming up, the thresholds may beset relatively lower to be more sensitive to traffic and purchaseactivity.

Example processes for obtaining and utilizing social network data andsocial network sites will now be discussed in further detail.

As previously discussed, in certain embodiments, the system (e.g., theticket system) determines (e.g., from information accessed from a socialnetwork database and/or a ticket system database) and provides fordisplay an indication as to which seats are assigned to “friends” of theuser via the interactive map. A friend may be someone that the user hasidentified as a friend to the system or to a source providinginformation to the system, or that the system has inferred from data(e.g., the user's contact database) is a friend of the user. A friendmay be a personal friend, a business partner, or other person that theuser wants to (or, in certain embodiments, that the system infers maywant to) share ticket/seat related information with. This enables a userto determine which friends have purchased tickets for the event, andfurther enables the user to purchase (or attempt to purchase) ticketsfor seats next to or close to one or more of the user's friends' seats.For example, event seats for which the user's friends have purchasedtickets, or for whom tickets have been purchased, can be colored ingreen (or other color), designated with a special icon, or otherwiseemphasized.

The system may obtain information regarding who the user's friends areusing one or more processes. For example, the user may agree (e.g., viaan opt-in control) or instruct a social networking site to shareinformation with the ticket system regarding relationship information ofthe user. The relationship information may identify who the user hasindicated are the user's friends and/or who others have indicated thatthey are friends of the user. The system may access such relationshipinformation via an application programming interface (API) associatedwith the social networking site or may access the information from othersources.

In addition to determining who the user's friends are, the system maydetermine whether the friends have purchased tickets for the event, havereceived tickets for the event, and/or have been tagged into a seat forthe event. For example, the system may have ticket records indicatingthe identity of purchasers, ticket holders, and seat tagginginformation, and may map the names or other identifiers associated withthe user's friends (e.g., obtained from the relationship information) tothe event venue seats using ticket records identifying the currentticket holder. In cases where the current ticket holder is not theoriginal purchaser of the ticket, the system may use contactinformation, such as names/addresses (e.g., email, SMS, MMS, or otheraddress(es)) of those to whom tickets have been electronically orphysically sent to), to identify who the current ticket holder is, evenif the current ticket holder is not the original ticket purchaser. Therelationship information and the ticket holder information may then beused to generate a seat map for the user, indicating where the user'sfriends are sitting or may be sitting. The seat map may be dynamicallyupdated to include and display the user's friends' comments,photographs, and/or videos submitted via a ticket system website, asocial network site, a computer/phone application, a short messagingservice, or otherwise.

Optionally, the ticket system may receive such relationship informationdirectly from the user instead of or in addition to receivingrelationship from a social network site. For example, a form may bepresented to the user asking the user to identify other users that theuser considers friends. For example, the user may be asked to identifyfriends by providing the friends' names, email addresses, physicaladdresses, phone addresses, and/or unique identifiers assigned by thesystem or selected by the friend, or otherwise identify the friends. Byway of further example, the user may be asked to provide the system withaccess to the user's contact database, which may be used to determinewho the user's friends are or might be.

In an example embodiment, if a user connects to a social network site,the ticket system receives from the social network system a useridentifier (user ID) from the social network system. The ticket systemmay then use the user ID to request and retrieve from the social networksystem information regarding the user, such as the user's profile and anidentification of those that are designated as friends of the user. Someor all of the retrieved information may then be displayed to other usersas discussed elsewhere herein.

If a user indicates that the user will be attending an event (e.g., byresponding, via an RSVP or otherwise, to an invitation to attend theevent from another user or by purchasing a ticket) for which tickets arebeing sold via the ticket system, the ticket system stores theindication may transmit the indication (e.g., the RSVP) to the socialnetwork system, which may post the indication. An event for the ticketedevent may then be established on the social network site, whereinselected users or all users may be provided with access to eventinformation via the social network site, as described below.

For example, the event may include a description of the ticketed event,and the date, time, venue, and address of the event. Privacy settingsmay be set for the event, which specifies who can view the eventinformation, and an invitation list may be defined as well. Invitationsto attend the event may be transmitted by the social network systemand/or ticket system to members of the invitation list. An entryregarding the event (including some or all of the foregoing eventinformation) may be displayed on one or more users' pages (e.g., in theform of a wall post), on a page associated with the ticket systemoperator, and/or may be otherwise provided for display.

As similarly discussed above, the ticket system may also storeuser-to-seat information. For example, if a user has opted to tag theuser's seats to an event (indicating who will be sitting in the seatspurchased by the user), the user-to-seat data may be stored. The storeddata may include an account identifier/userID of the user for an accountstored by the ticket system and/or an account identifier/userIDassociated with the user's social network site account, stored inassociation with seat identifiers for the user's seats. Optionally, suchuser-to-seat tag data is not transmitted to the social network system,although in certain embodiments, it may be transmitted to the socialnetwork system.

When a user accepts an invitation or tags seats and friends to an event,the ticket system may construct a wall post and transmit the wall postto the social network system. In turn, the social network system mayreturn a wall post identifier, which is received by the ticket systemand which may be used to track the wall post and to recall or delete thewall post if necessary or if desired.

By way of example, a constructed wall post may include some or all ofthe following information

1. Event details: name (e.g., performer name), date, time venue,address, webpage/URL of event page and/or of performer/artist page.

2. Names of friends that were tagged for the event (optionally,excluding or including the friends' social network site user IDs).

In an example embodiment, if a user tags her/his friends to an event, orinvites the user's friends to an event, the ticket system constructs asocial network site user-to-user application (“app”) request for asocial network site app of the ticket system for the appropriate domainor, in addition or instead, the ticket system may construct a socialnetwork site user-to-user inbox message or other mechanism to deliver amessage to the recipient user. In turn, the social network systemreturns an app request ID which is received by the ticket system. Theticket system may use the app request ID and/or inbox message ID totrack the request to thereby track individual app request and inboxmessage statuses and act accordingly, or to recall the app requestinvitation or inbox message when necessary or desired. The ticket systemmay store the individual user-to-user app requests or inbox message in adatabase.

An example app request or inbox message may include some or all of thefollowing information:

1. Event details: name (e.g., performer name), date, time venue,address, webpage/URL of event page and/or of performer/artist page.

2. An identifier (e.g., a userID) of the social network site userinitiating or transmitting the request.

An indication that the user has purchased seats for the event and/or aseat location identifier (e.g., section, row, seat number) may be postedby the ticket system and/or the social network system for display on theuser's social networking site page or other page/document associatedwith the user (e.g., the user's own blog or website). This enables otherusers that have permission to view the user's page and/or activityupdates to view or be notified (by email, SMS message, MMS message,physical mail, automated voice message, or otherwise) of the user'sticket purchase and/or the seat assigned to the user.

Optionally, a link may be provided on the user's social network sitepage, which, if activated, will cause a ticket purchase user interface,which enables the viewer to purchase tickets for the event, optionallyfor seats near the user's seats. Optionally, the system tracks whenpurchases have been made by users that navigated to the event ticketpage via a link associated with another user's page, and made ticketpurchases, and provides a benefit (e.g., a discount, a credit, apayment, a free musical item (e.g., a CD, MP3 song, etc.), a article ofclothing, etc.) to such user whose page included the link.

FIG. 23 illustrates an example user interface that enables a user toindicate to others that the user is attending an event. In this example,a share control (“Attending”) is presented to a user substantiallyimmediately after the user has purchased a ticket for an event, duringthe same session and at the same site at which the user purchased theticket. Optionally, in addition or instead, the share control (whichcould be a link) may be emailed or transmitted to the user via SMS, MMS,a telecommunications device application, a webpage, an interactiveseating map, or otherwise, sometime after completion of the ticket sale.In this example, the user interface instructs the user to activate theshare control (“Attending”) if the user wants to inform others (e.g.,whom the user has designated as friends, other groups of people, oreveryone), via a social networking webpage or otherwise, that the userwill be attending the event. If the user activates the sharing control(“Attending”), an indication that the user will be attending the eventis posted to the user's social network webpage and/or the indication isotherwise provided to other users via email, SMS, MMS, atelecommunications device application, a webpage, an interactive seatingmap, or otherwise. The indication may optionally include the name of theevent, the date of the event, the time of the event, the event venue,and/or the venue location.

FIG. 24 illustrates another example user interface enabling a user toindicate to others that the user is attending an event, as similarlydiscussed above with respect to FIG. 23. In this example, a sharecontrol (“Attending”) is presented to a user substantially immediatelyafter the user has purchased a ticket for an event, during the samesession and at the same site at which the user purchased the ticket.Optionally, in addition or instead, the share control (which could be alink) may be emailed or transmitted to the user via SMS, MMS, atelecommunications device application, a webpage, an interactive seatingmap, or otherwise sometime after completion of the ticket sale. In thisexample, the user interface includes a field via which the user canenter content (e.g., text, images, graphics, and/or videos) to bepublished in association with an indication that the user is attendingthe event. The indication may optionally include the name of the event,the date of the event, the time of the event, the event venue, and/orthe venue location. If the user activates a “publish” control, theindication that the user will be attending the event and the userentered content are posted to the user's social network webpage and/orthe indication is otherwise provided to other users via email, SMS, MMS,a telecommunications device application, a webpage, an interactiveseating map, or otherwise.

FIG. 25A illustrates another example user interface enabling a user toindicate to others that the user is attending an event and enabling theuser to indicate which of the user's friends will be attending and/orthe user would like to invite to attend. In this example, images of theuser's friends (which may have been accessed from a social network site)are presented in association with the friends' names/identifiers.Optionally, the user can limit the friends presented via the userinterface by searching for one or more particular users. For example,the user can search by name, geographical location, group membership,interests, music preferences, etc. The user can select (e.g., byclicking on the names/pictures of the friends) which of the friends areattending the event and/or the user would like to invite to attend. Afield is provided via which the user can designate who is permitted toview, via a seat map, which seats the user purchased tickets for. Forexample, the user may be able to designate that the seating informationis to be viewable by “everyone”, “friends”, pre-specified groups ofpeople, specific individuals, etc. As similarly discussed above, in thisexample the user interface is presented to a user substantiallyimmediately after the user has purchased a ticket for an event, duringthe same session and at the same site at which the user purchased theticket. Optionally, in addition or instead, the user interface may belater provided to the user via one or more of the techniques describedabove or otherwise.

Once the user tags other users via the user interface illustrated inFIG. 25A, the user activates a “next” control, and the example userinterface illustrated in FIG. 25B is provided for display. The exampleuser interface presents a preview of what will be posted on the user'ssocial network page/document (which may be presented via a browser,telecommunications device application, or otherwise). The user can thenactivate a publish control to publish the attendance information, oractivate a cancel control to prevent such publication.

FIG. 25C illustrates an example social network page with thenotification illustrated in FIG. 25B presented thereon. A notificationmay be provided via the social network site or otherwise to the userstagged/selected via the user interface of FIG. 25A, inviting them toattend the event. The notification may include a link, which ifactivated, will cause a ticket purchase user interface for the event tobe presented to the invited user. The ticket purchase user interface maybe hosted by the ticket system discussed above.

FIG. 26A illustrates an example ticket purchase user interface via whicha user can select specific seats for an event and can view which oftheir friends have purchased tickets or otherwise have tickets for theevent, and where they will be sitting. In this example user interface,the user can activate a link, which will initiate a connection to asocial network site and/or database that stores information on who theuser has designated as friends. To encourage the user to activate thelink, the user interface presents a seat identifier (e.g., section, row,seat designations) and indicates that if the user wants to know who issitting at seat corresponding to the seat identifier, the user shouldactivate the link.

FIG. 26B illustrates an example user interface provided for display tothe user if the user activates the link discussed above with respect toFIG. 26A. As illustrated, icons (“f” in this example) are displayed onthe interactive seat map, indicating in which seating section the user'sfriends will be sitting. The icon may indicate the source of theidentification of friends (e.g., “f” may indicate Facebook®). Differenticons may be used to represent different social networks. If the userpoints at or hovers a cursor over a section where a friend is sitting(e.g., which includes one of the foregoing icons), the names and/orpictures and/or of the friends and/or a count as to the number offriends sitting in the section will be displayed. This informationenables the user to quickly find out which friends are attending theevent (or intend to attend) and where they are sitting (or intend tosit), which may affect the user's decision as to whether or not topurchase a seat ticket for the event, and which seat to purchase aticket for. The user can then purchase tickets via ticket purchasecontrols displayed in conjunction with the interactive seat map.

FIG. 26C illustrates a zoomed view of the interactive map of FIG. 26B,wherein individual seats may be viewed. If the user points at or hoversa cursor over a seat where a friend is sitting (e.g., which includes oneof the foregoing icons), the name (which may be the friends legal nameor a nickname/alias) and/or photograph of the friend will be displayed.A control is provided via which a user can tag herself/his self into theseat map (e.g., indicating that the user intends to or is consideringpurchase a ticket for the seat) so that when the user's friends via theseat map for the event, the seat map will display the user's name and/orimage. The user can then purchase tickets via ticket purchase controlsdisplayed in conjunction with the interactive seat map.

FIG. 26D1 illustrates a user's social network apps page (via which thirdparty content may be displayed) indicating that a ticketing app hasreceived an invitation to attend an event, including an “accept” controlvia which the user can accept the invitation. If the user accepts theinvitation, a ticket purchase user interface of for the event pay bepresented via the user's browser or other application and the user canpurchase a ticket for the event.

FIG. 26D2 illustrates an interactive seat map including a user interfaceproviding a tagging control via which the user can tag herself/himselfinto the seat map so that when the user's friends views the seat map forthe event, the seat map will display the user's name and/or image (orother identifier). FIG. 26E illustrates an interactive seat mapincluding a user interface indicating that more than one user has beentagged in a given seat. The user interface presents photographs and/ornames of users that have been tagged for the given seat, and enables theuser to tag herself or himself at that seat (e.g., indicating that theuser intends to or is considering purchase a ticket for the seat) sothat when the user's friends via the seat map for the event, the seatmap will display the user's name and/or image (or other identifier).

FIG. 26F illustrates an interactive seat map presented to a user afterpurchasing a ticket for an event. The user may have brought a ticket forhimself/herself or for another person. A user interface is provided fordisplay which lists a seat identifier (e.g., seat section, row, number)corresponding to the purchased ticket and asks the user who is sittingin the seat. The user interface provides a control via which the usercan indicate who is sitting in the seat (e.g., by entering/selecting thename and/or photograph of the person that will be sitting in the seat).If the user purchased several seat tickets for the event, a userinterface may list each of the corresponding seat identifiers and mayoptionally present the names/photographs of the user's friends (e.g.,accessed from a social network site). The user can select friends fromthe list and indicate which friends will be sitting in which seat. Inaddition, a user interface is provided via which the user can specifywho or which groups of people can view the tagging performed by theuser.

FIG. 27 illustrates an example augmented reality user interface thatprovides a view of a physical venue augmented by computer-generatedvisual and/or audio information. In this example, an application isdownloaded and hosted on a user's telecommunications device (e.g., acamera equipped phone). As the user points the device camera at a viewof the venue, the application and/or a remote server in communicationwith the application utilizes information from the device to determine(e.g., estimate) what is in the view of the camera. The determinationcan be based at whole or in part, on:

GPS location information,

cell tower location information,

WiFi location information,

a compass internal to the device that provides heading information(e.g., relative to magnetic north),

an accelerometer internal to the device (which can also be used toprovide tilt information),

gyroscopic orientation information from a gyroscope (e.g., a 2 or 3 axisgyroscope which may provide two or three dimensional attitudeinformation (e.g., pitch, roll, and yaw) and, in combination with theaccelerometer output, rotation rate) located within the device,

object recognition performed by analyzing the image to identifylandmarks (which may be structural landmarks, such as walls, columns,doorways, seats, and/or may be active or passive beacons, such as codedsigns (e.g., where each sign has a unique visual code and the signs arestrategically placed are columns, walls, etc.), etc.), faces, etc.,

and/or other information.

In order to make the determination, some or all of the foregoinginformation may be used in combination with a 3D map of the venue (whichmay include beacon placement location information, if such exist and/orother landmark identifications and locations) and/or photographs and/orwhat is actually physically present in the venue as captured via arear-facing camera lens on the user's smart phone, PDA device, or tabletdevice. In particular, some or all of the forgoing information may beused to determine the device's pose (position and orientation). Forexample, GPS information can be used to determine the latitude andlongitude location of the user device, and gyroscopic orientationinformation can be used to determine the lens angle with reference toground or other reference point or plane. Upon receiving an indication(e.g., via the application) that the device's camera is active(capturing images), and by knowing the user device pose, and the systemcan determine what is being displayed on the device's display.

The application and/or server can also obtain seating information (e.g.,including identifiers/names associated with ticket holders) and userfriend information (e.g., identifiers/names associated with the user'sfriends obtained from the ticket system and/or a social network systemdata stores) which may be compared to determine where and in which seatsthe user's friends are sitting. The server can forward to theapplication information as to where in the device display such seat andfriend information are to be displayed. The application can then overlayonto the image captured by the camera names, photographs, and/or seatidentifiers of the user's friends so that the user can visually seewhere the user's friends are located. Optionally, the system may receivecomments, photographs, and/or videos posted by event attendees duringthe event.

For a given user, the system may determine who the user's friends are,and then stream the user's friends' comments, photographs, and/or videossubmitted via the application, a short messaging service interface, asocial network interface, or otherwise, (and received by the system) insubstantially real-time to the user's device for display via theaugmented reality user interface. In addition, other types ofinformation may be overlaid onto the camera view, such as highlights orother emphasis around entrances to bathrooms, concessions, otheramenities, exits, the user automobile, etc. The emphasis may be visuallycoded (e.g., color coded, icon coded, etc.), where different codes maybe used to identify different features or types of information (e.g.,the type of service provided by an amenity (e.g., food, a bathroom, awater fountain, an automated teller machine).

In addition, the system may determine which of the user's friends havearrived at the venue based on an indication that their ticket (which maybe a physical ticket, an electronic ticket in their phone, a credit cardused to purchase the right to attend, etc.) has been scanned at thevenue, via a presence signal received from the friends' mobilecommunication devices while at the venue (e.g., GPS information providedvia a phone app hosted on the friends mobile communication devices), viaan affirmative action by the friend (e.g., by activating an “I havearrived” control via an app hosted on the friend's mobile communicationdevice), or otherwise (the system may similarly determine if the user isat the venue). When the user's device is pointing at a friend's seat,the system may code (e.g., color code, icon code, text code, etc.) theseat to indicate the friend has arrived (or that a friend has notarrived if their presence has not been detected). In addition orinstead, a list may be presented to the user via an application or webpage indicating which of the user's friends have arrive and which havenot yet arrive.

In certain embodiments, the ticket system may determine if the user'sview includes a performer, may access information regarding theperformer, and cause the accessed information to be displayed via theuser's device in association with the image of the performer.

In certain embodiments, the ticket system may determine if the user'sview includes seats for which event tickets have not yet been purchased.The system may optionally identify the seats as being available to theuser via an augmented reality indication overlaying the view (e.g.,textually, graphically, or otherwise). A control may be provided viawhich the user can purchase at a specified price, via their device, aticket/upgrade for the seat, which then may be electronically deliveredto their device to be displayed or otherwise communicated to others(e.g., to an usher) to indicate that the user has a right to utilize theseat. Optionally, before indicating to the user that a seat isavailable, the system may first determine if the seat is a better seatthan the user's current seat (e.g., have a better view, is closer to thestage or playing field), based on rankings or other information storedin a database. If the seat is not better (e.g., has a similar, the same,or lower ranking than the user's current seat), optionally the systemdoes not identify the seat as being available to the user.

FIG. 28 illustrates an example ticket selection and checkout processwhich may be executed by a computing system, such as system 102discussed above. At state 2802, the process receives a user selection ofan event (e.g., via a menu selection, a user initiated search,activation of an event link, or otherwise), and the process causes a mapof the event venue to be displayed on the user's terminal (e.g., laptop,desktop, tablet computer, cell phone, television, etc.). By way ofexample, the map may be provided for display via a ticketing website ora ticketing application hosted on a computing device. The venue map mayhave seating sections demarcated (e.g., using polygons). The sectionsand/or seats may be color coded and/or otherwise coded (e.g., usingicons, text, animations, 3D effects, etc.) via to provide informationregarding the sections and/or seats (e.g., location information, seatstatus information, prices, offer code requirements, view information,etc.), as discussed above.

The process may cause a field to be presented via which the user mayenter an offer code. For example, the offer code may entitle the user topurchase seats that are not available to the general public or tocertain people absent the offer code. In addition or instead, the offercode may entitle the user to reduced prices/discounts on some or allseat tickets and/or may entitle the user to a package (e.g., a musicalrecording, food, and/or an item of clothing, in addition to the eventticket).

If the user has been identified by the system (e.g., via a login processat a ticketing website, a social network website, via a token, a uniqueuser terminal identifier, or otherwise identified), the map may becustomized for the user. For example, at state 2803, automatically or inresponse to a user instruction to show where the user's friends aresitting, the process may identify certain other people as having asocial relationship with the user (which, for convenience, will bereferred to as “friends) from information accessed from a social networkaccount of the user. The database may be part of a social network sitehosted by the ticketing system or separately hosted and operated. Inaddition, information regarding such friends (e.g., names, emailaddresses, wall postings, activities, etc.) may be accessed from thesocial network account of such people. The process may use identifyinginformation regarding the friends (e.g., their names, emails addresses,etc.) to locate, in a ticketing database, user records that include someor all of such identifying information. A ticketing database user recordmay indicate which seat tickets for which events are being held by therespective user. The process may then determine which friends are ticketholders for the event and determine for which seats the friends holdtickets. The map may then be generated or modified to include indicatorsas to where friends of the user are sitting (e.g., at a section leveland/or at a seat level). The indicators may be in the form of colorcoding, icon, friend name, friend photograph, or otherwise. Differentindicators may be used depending on how detailed the map being presentedto the user is.

At state 2804, the process receives from the user a selection of a venuesection (e.g., by the user clicking on or hovering a cursor over thesection in the map) or a modification of the user's search criteria(e.g., by the user specifying or modifying a desired price range, tickettype, package type, seating area, shade seating, seating in the sun,covered seating, aisle seating, bathroom adjacent seating, concessionadjacent seating, exit adjacent seating, friends seating, etc.).

At state 2806, the map provided for display to the user is updated,optionally in substantially real-time, to reflect the section selection,the modified search criteria, and/or system initiated modifications(e.g., to reflect the change in status of seats). For example, if theuser selected a section, the process may provide, via the user terminal,a zoomed view of the section so that seats can be individually viewedand selected. If the user modified the search criteria, the map coloring(or other indicator) may indicate which sections and/or seats match theuser's search criteria and/or the degree to which the sections and/orseats match the user's search criteria. At state 2808, a user seatselection is received (e.g., by a user clicking on a seat icon in themap or by entering a seat identifier into a field), and the selectedseat(s) are added to the user's selected seat list and are assigned areserved status. In this example embodiment, when the seats are in areserved state, other users may not purchase the tickets, althoughoptionally they can be wait-listed for the tickets, wherein thewait-listed user may be notified when the reserved seats becomeavailable for purchase (and are no longer reserved by another user). Incertain embodiments, the reserved seats may be released for others topurchase (wherein the status is changed from reserved to available), ifthe user does not complete the ticket purchase and/or certain stages ofthe ticket purchase, within a specified period of time.

At state 2810, the user activates a checkout control, and the processprocesses the order (e.g., obtains or retrieves payment information,shipment information, etc.), and causes the ticket(s) to be delivered tothe user (e.g., electronically or as a physical ticket) and/or enablesan existing user physical or electronic document (e.g., a credit card,license, membership card, etc.) to be used as a ticket. The user may beautomatically be tagged into a seat selected by the user and/orpurchased by the user, or the user may manually instruct the process totag the user into the seat. Optionally, a user interface is provided viawhich the user can tag others into one or more seats.

At state 2812, the process may receive an instruction from the user totransmit invitations to attend the event to one or more people and/or agroup of people designated by the user. The process may then transmitsuch invitations to those so designated directly via the system 102 orvia another system (e.g., via the social network system 122 illustratedin FIG. 1). The invitation may indicate by user name and/or photographthat the user is attending the event (e.g., wherein the invitationincludes the event name, date, time, venue, and/or user seat location),and may provide a control, which when activated will cause a ticketinginterface to be presented to the invitation recipient via which the usermay purchase a ticket for the event (e.g., using the process illustratedin FIG. 28).

At state 2814, the process may post to one or more pages (e.g., to asocial network wall pages of the user, to an event-specific page for theevent, to the user's friend's pages, and/or other pages), an entryindicating that the user is attending the event, wherein the postingoptionally includes some or all of the following information: eventname, date, time, venue, user seat location, number of people attending,number of seats available, etc.

Optionally, once at the venue to attend the ticketed event, the systemcan provide for display on a mobile communications device of the user(or other terminal), a mapping showing where friends of the user haveseats, and may further color code (or otherwise indicate) the seats toindicate which friends have already arrived at the venue. For example,seats may be colored green to indicate seats that are assigned to theuser's friends, and seats may be colored gold to indicate which seatsare assigned to the user's friends that have arrived at the event. Thesystem may determine which friends of the user have arrived viainformation scanned from physical or electronic tickets of the user'sfriends upon entry to the venue and/or via location information providedvia a mobile terminal of the user (e.g., a cell phone). For example, ascanner may scan:

-   -   a ticket barcode or other code on a physical ticket;    -   a ticket barcode or other code displayed via a user phone        display or other terminal display;    -   a near field communication device embedded in the user's phone        or other device;    -   an RFID (Radio-frequency identification) tag; and/or    -   a user identification document (e.g., a driver's license, credit        card, fan card, membership card, etc.) associated with an        admission right (e.g., where the user can utilize a credit card        used to purchase a ticket as the ticket, or where the user has a        driver's license on file on the system which is associated with        an admission right when the user purchases a ticket).

In addition or instead, a gate keeper, attendees, or other person maymanually key in, via a terminal, an indication as to who has arrived atthe event venue.

The system may store an indication as to who has arrived at the eventbased at least in part on the scanned information. Then, when a userviews a map via a terminal, the system identifies the user (e.g., vialog in information, a unique identifier associated with the user'sterminal, a unique identifier associated with the user's viewingapplication, or otherwise), identifies friends of the user that havetickets for the event, identifies which of those friends have arrived,and displays corresponding information on the map. The map may beupdated, optionally in substantially real time, to indicate changes inthe friends' statuses. For example, when a friend arrives at the venueor purchases a ticket, the map may be accordingly updated to soindicate. The map may indicate (via text or otherwise) at what time afriend arrived, the current location of the friend, and/or otherinformation.

In certain embodiments, the system may track a user's location at anevent venue and/or outside an event venue to thereby provide locationbased services. For example, the user's location may be tracked at thevenue (e.g., via GPS, cell tower, and/or WiFi information received bythe user's mobile device, and transmitted via a ticket-relatedapplication hosted on the mobile device to the system; or via atransceiver that receives information from a near field communicationdevice carried by the user). Such information may be used to determine auser's location at the event venue, and to provide information fordisplay to the user (via a map, text information, and/or otherwise) thatmay be of interest to the user related to the user's current locationand/or direction of movement. For example, the system may utilize theuser's location information, in conjunction with venue layoutinformation stored in a database, to determine the nearest restrooms,concessions, and/or exits relative to the user, and to providedirections to such destinations and/or display a map of suchdestinations while showing the user's current location on the map.

By way of further example, a map mode may be changed based on the user'slocation. By way of illustration, a map of a venue may be displayed in aticket purchase mode or in an at-the-venue mode, wherein differentinformation may be displayed depending on the mode. For example, when ina ticket purchase mode, a venue event map may display information onticket pricing and seat availability, and may provide ticket purchasecontrols, as discussed above. Optionally information regarding thelocation of concessions, bathrooms, etc., is not displayed or is hidden(although optionally such may still be accessible if the user activatesa corresponding control). When in an at-the-venue mode, the ticketpricing and seat availability information and/or the provide ticketpurchase controls may be removed or not displayed (although optionallythey may still be accessible if the user activates a correspondingcontrol). However, in the at-the-venue mode, information as to who hasarrived may be displayed and other information of interest to anattendee may be displayed (e.g., locations of exits, concessions,bathrooms, etc.). Optionally, the mode is automatically switched fromticket purchase mode to at-the-venue mode when the user enters the venueon the day of the event (as detected when the user's physical orelectronic ticket is scanned or via information transmitted from theuser's terminal, such as GPS or WiFi location information).

Optionally, when the user is at the venue for an event (as may bedetermined using one or more of the location determination techniquesdescribed herein), an application installed on the user's terminal willautomatically display the venue map for the event, without requiring theuser to manually select the specific map for the venue (although theuser may need to open initiate the application and/or may need toindicate that the user wants to view a venue map without having to namethe venue or select the specific venue from a list of venue—such as byactivating a “show current venue” control). The map may be transmittedto the user terminal via a ticket system.

In addition, such user location information may be used to determineline lengths/wait times at concessions, bathrooms, exits, or otherlocations/destinations selected by the user and/or the system. Forexample, if the system determines, from user location information and avenue layout, that a user is standing within a certain distance of afacility (e.g., a bathroom, concession stand, or exit) and appears to bemoving in the direction of the facility within a certain speed range(e.g., slower than 0.2 feet/second), the system may infer that the useris waiting in line for the facility. The system may further use theforegoing location and movement information to estimate the length ofthe line, as expressed in time (e.g., a 4-5 minute wait) and/or distance(e.g., a 20 foot line). Such line length information can be transmittedfor display on the user's terminal (e.g., via a map, textually, and/orvia an email, SMS, MMS message(s)) and/or on other users' terminals. Amap and/or text listing may be provided for display via a user terminal,providing line wait information for a plurality of destinations of agiven type (e.g., bathrooms), so that the user can select a destinationwith an acceptable or shortest line length. Optionally, the systemdetermines from the line lengths, a user's current location and/ormovement information, and the locations of destinations of a given type,which of the destinations of the given type the user will likelyreach/be able to utilize the quickest, and may so identify thecorresponding destination to the user as being the fastest available.

For example, if a bathroom within 100 feet of a user has a 5 minuteline, and a bathroom within 200 feet of the user has a 1 minute line,the system may determine that the bathroom located 200 feet from theuser will be usable by the user quicker than the closer bathroom. Thesystem may transmit for display to the user such time information (via amap and/or text listing) for a plurality of destinations of the giventype and may rank and/or list the destinations in order of the estimatedrelative speed the destinations may be reached or usable.

In addition, communications may be transmitted to a given event attendeebefore, during, and/or after an event, requesting information and/oroffering goods and services. For example, the communication may betransmitted to a terminal (e.g., computer, phone, television) of anattendee the same day or the day after the event, while the event isstill fresh in the attendee's mind, asking the attendee to submit areview of the event, which may then be posted online in association withan offer to sell tickets to another event by the same performer. Inaddition or instead, the communication may offer musical recordings(e.g., in the form of a CD, DVD, Blu-ray disk or digital download) ofthe performer (e.g., a live recording of the concert event the attendeeattended or another recording of the performer) for sale or at no chargeto the user.

While certain embodiments may be illustrated or discussed as havingcertain example components, additional, fewer, or different componentsmay be used. Process described as being performed by a ticket system maybe performed by a user terminal or other system or systems. Processesdescribed as being performed by a user terminal may be performed by aticket system or other system or systems. Data described as beingaccessed from a given source, such as a ticket system database, may bestored by and accessed from other sources, such as a user terminal orsocial network database. Further, with respect to the processesdiscussed herein, various states may be performed in a different order,not all states are required to be reached, and fewer, additional, ordifferent states may be utilized. While certain embodiments may refer tocoding certain information (e.g., information regarding seats on aseating chart) using a particular technique, other techniques, includingcolor, textual, graphical, animations, video, audio, and/or otherindicators may be used instead or in addition. User interfaces describedherein are optionally presented (and user instructions may be received)via a user computing device using a browser, other network resourceviewer, or otherwise. For example, the user interfaces may be presented(and user instructions received) via an application (sometimes referredto as an “app”), such as an app configured specifically forticket-related activities, installed on the user's mobile phone, laptop,pad, desktop, television, set top box, or other terminal. Variousfeatures described or illustrated as being present in differentembodiments or user interfaces may be combined into the same embodimentor user interface.

While the disclosure may reference to a user hovering over or pointingat a particular item, such as a section or seat, other techniques may beused to detect an item of user interest. For example, the user may clickon such an item to show interest, touch the item via a touch screen, orotherwise indicate an interest.

Various aspects and advantages of the embodiments have been describedwhere appropriate. It is to be understood that not necessarily all suchaspects or advantages may be achieved in accordance with any particularembodiment. Thus, for example, it should be recognized that the variousembodiments may be carried out in a manner that achieves or optimizesone advantage or group of advantages as taught herein withoutnecessarily achieving other aspects or advantages as may be taught orsuggested herein. Further, embodiments may include several novelfeatures, no single one of which is solely responsible for theembodiment's desirable attributes or which is essential to practicingthe systems, devices, methods, and techniques described herein. Inaddition, various features of different embodiments may be combined toform still further embodiments. For example, aspects found in differentuser interfaces may be combined to form still further user interface.

1. A system for providing an interactive seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; providing the map to a user terminal for display as an interactive seat map including sections and/or individual seats in association with: an interface via which the user can specify a price range with respect to seat tickets; an interface via which the user can specify at least a first offer, wherein the first offer provides at least one of the following: a reduced price relative to a listed price with respect to at least one seat ticket; a reduced price relative to a listed price with respect to an ancillary product or service in association with at least one ticket purchase; an entitlement to purchase seat tickets for a certain category of seats if a corresponding offer code is supplied; receiving, via a data interface, relationship information with respect to the user, wherein the relationship information includes identifications of one or more friends of the user; wherein, in at least partly in response to a user specified price range and/or a user specified offer, the interactive seat map emphasizes sections and/or seats corresponding to the user specified price range and/or the user specified offer; accessing seat information with respect to one or more friends of the user; causing, at least in part, the interactive seat map to indicate sections and/or seats where at least a portion of the user's friends have tickets for; and receiving and processing a ticket purchase request for at least one seat selected by the user via the interactive seat map.
 2. The system as defined in claim 1, wherein the interactive seat map is configured to: display a first map including substantially all event venue seating sections in a first portion of the interactive seat map, and display and a second map, including an expanded view of at least one user selected seating area, in a second portion of the interactive seat map, wherein the user can select a seating area in the first map to be displayed in the expanded view of the second map.
 3. The system as defined in claim 1, further comprising an application programming interface configured to access the relationship information from a social network system.
 4. The system as defined in claim 1, wherein the interactive seat map provides an interface via which the user can tag at least one user into a venue seat for the event.
 5. The system as defined in claim 1, wherein the interactive seat map provides an interface providing the user an option to have an indication that the user will be attending the event posted to a social network site.
 6. The system as defined in claim 1, wherein the interactive seat map is configured to display information regarding seat availability in a first section in response to the user selecting a representation of the first section, wherein the representation of the first section does not include a representation of individual seats.
 7. The system as defined in claim 1, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and which seats the user has purchased tickets for.
 8. The system as defined in claim 1, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and for which seats a current ticket holder for those seats has indicated a willingness to resell their seat tickets.
 9. The system as defined in claim 1, wherein the interactive seat map, wherein color coding is not used to emphasize sections and/or seats corresponding to the user specified price range.
 10. A method comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; providing the map to a user terminal for display as an interactive seat map including sections and/or individual seats in association with: an interface via which a user can specify a price range with respect to seat tickets; an interface via which the user can specify at least a first offer, wherein the first offer provides at least one of the following: a reduced price relative to a listed price with respect to at least one seat ticket; a reduced price relative to a listed price with respect to an ancillary product or service in association with at least one ticket purchase; an entitlement to purchase seat tickets for a certain category of seats if a corresponding offer code is supplied; receiving, via a data interface, relationship information with respect to the user, wherein the relationship information includes identifications of one or more friends of the user; wherein, in at least partly in response to a user specified price range and/or a user specified offer, the interactive seat map emphasizes sections and/or seats corresponding to the user specified price range and/or the user specified offer; accessing seat information with respect to one or more friends of the user; causing, at least in part, the interactive seat map to indicate sections and/or seats where at least a portion of the user's friends have tickets for; and receiving and processing a ticket purchase request for at least one seat selected by the user via the interactive seat map.
 11. A system for providing an interactive seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; transmitting the map for display as an interactive seat map on a user terminal in association with: an interface via which a user can specify a price range with respect to seat tickets; receiving, via a data interface, relationship information with respect to the user, wherein the relationship information includes identifications of one or more friends of the user; accessing seat information with respect to one or more friends of the user; and wherein, in response to a user-specified price range, the interactive seat map emphasizes sections and/or seats corresponding to the user specified price range, and wherein the interactive map indicates where the one or more of the user's friends are sitting; receiving and processing a ticket purchase request for at least one seat selected by the user via the interactive seat map.
 12. The system as defined in claim 11, wherein the interactive seat map is configured to display substantially all ticketed individual seats at the same time, wherein each of the ticketed individual seats is separately represented by a corresponding representation.
 13. The system as defined in claim 11, wherein the interactive seat map is configured to: display a first map including substantially all event venue seating sections in a first portion of the interactive seat map, and display and a second map, including an expanded view of at least one user selected seating area, in a second portion of the interactive seat map, wherein the user can select a seating area in the first map to be displayed in the expanded view of the second map.
 14. The system as defined in claim 11, further comprising an application programming interface configured to access the relationship information from a social network system.
 15. The system as defined in claim 11, wherein the interactive seat map provides an interface via which the user can tag at least one user into a venue seat for the event.
 16. The system as defined in claim 11, wherein the interactive seat map provides an interface providing the user an option to have an indication that the user will be attending the event posted to a social network site.
 17. The system as defined in claim 11, wherein the interactive seat map is configured to display information regarding seat availability in a first section in response to the user selecting a representation of the first section, wherein the representation of the first section does not include a representation of individual seats.
 18. The system as defined in claim 11, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and which seats the user has purchased tickets for.
 19. The system as defined in claim 11, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and for which seats a current ticket holder for those seats has indicated a willingness to resell their seat tickets.
 20. The system as defined in claim 11, wherein the interactive seat map, wherein color coding is not used to emphasize sections and/or seats corresponding to the user specified price range.
 21. A method comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; transmitting the map for display as an interactive seat map on a user terminal in association with: an interface via which the user can specify a price range with respect to seat tickets; receiving, via a data interface, relationship information with respect to the user, wherein the relationship information includes identifications of one or more friends of the user; accessing seat information with respect to one or more friends of the user; and wherein, in response to a user specified price range, the interactive seat map emphasizes sections and/or seats corresponding to the user specified price range, and wherein the interactive map indicates where the one or more of the user's friends are sitting; receiving and processing a ticket purchase request for at least one seat selected by the user via the interactive seat map.
 22. A system for providing a venue seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; receiving, via a data interface, relationship information with respect to a user, wherein the relationship information includes identifications of one or more friends of the user; accessing seat information with respect to one or more friends of the user; and causing the seat map to indicate where the one or more of the user's friends are sitting.
 23. The system as defined in claim 22, wherein the interactive seat map is configured to: display a first map including substantially all event venue seating sections in a first portion of the interactive seat map, and display and a second map, including an expanded view of at least one user selected seating area, in a second portion of the interactive seat map, wherein the user can select a seating area in the first map to be displayed in the expanded view of the second map.
 24. The system as defined in claim 22, further comprising an application programming interface configured to access the relationship information from a social network system.
 25. The system as defined in claim 22, wherein the interactive seat map provides an interface via which the user can tag at least one user into a venue seat for the event.
 26. The system as defined in claim 22, wherein the interactive seat map provides an interface providing the user an option to have an indication that the user will be attending the event posted to a social network site.
 27. The system as defined in claim 22, wherein the interactive seat map is configured to display information regarding seat availability in a first section in response to the user selecting a representation of the first section, wherein the representation of the first section does not include a representation of individual seats.
 28. The system as defined in claim 22, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and which seats the user has purchased tickets for.
 29. The system as defined in claim 22, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and for which seats a current ticket holder for those seats has indicated a willingness to resell their seat tickets.
 30. A method comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; receiving, via a data interface, relationship information with respect to a user, wherein the relationship information includes identifications of one or more friends of the user; accessing seat information with respect to one or more friends of the user; and causing the seat map to indicate where the one or more of the user's friends are sitting.
 31. A system for providing an interactive seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; accessing status information regarding a plurality of venue seats, the status information indicating seat availability; transmitting the map for display as an interactive seat map on a user terminal, wherein the interactive map indicates seat availability; providing a user interface via which: a user may select a seat for which a ticket is already held by a ticket holder that had previously acquired the ticket, and submit an offer, including a user specified price, to purchase the ticket for the selected seat from the ticket holder; if the user submits an offer to the ticket holder, transmitting the offer to the ticket holder, and processing an acceptance or refusal of the offer from the ticket holder.
 32. The system as defined in claim 31, wherein the interactive seat map is configured to: display a first map including substantially all event venue seating sections in a first portion of the interactive seat map, and display and a second map, including an expanded view of at least one user selected seating area, in a second portion of the interactive seat map, wherein the user can select a seating area in the first map to be displayed in the expanded view of the second map.
 33. The system as defined in claim 31, further comprising an application programming interface configured to access relationship information of the user from a social network system, wherein the interactive seat map is configured to display an indication as where at least one person, with whom the user has a relationship as determined via the relationship information, will be sitting at the event venue.
 34. The system as defined in claim 31, wherein the interactive seat map provides an interface via which the user can tag at least one user into a venue seat for the event.
 35. The system as defined in claim 31, wherein the interactive seat map provides an interface providing the user an option to have an indication that the user will be attending the event posted to a social network site.
 36. The system as defined in claim 31, wherein the interactive seat map is visually coded to indicate which seat are available, which seats are unavailable and which seats the user has purchased tickets for.
 37. A method, comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing status information regarding a plurality of venue seats, the status information indicating seat availability; transmitting the map for display as an interactive seat map on a user terminal wherein the interactive map indicates seat availability; providing a user interface via which: a user may select a seat for which a ticket is already held by a ticket holder that had previously acquired the ticket, and submit an offer, including a user specified price, to purchase the ticket for the selected seat from the ticket holder; if the user submits an offer to the ticket holder, transmitting the offer to the ticket holder, and processing an acceptance or refusal of the offer from the ticket holder.
 38. A system for providing a seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing system to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; accessing purchase process information, wherein the purchase process information indicates: a first ticket for a first seat is to be offered for sale via a first purchase process type, and a second ticket for a second seat is to be offered for sale via a second purchase process type different than the first purchase process type; accessing status information regarding a plurality of venue seats, the status information indicating seat availability; transmitting the seat map for display on a user terminal, wherein the seat map indicates seat availability, and where the seat map visually indicates that: the first ticket for the first seat is available for purchase via the first purchase process type, and the second ticket for the second seat is available for purchase via the second purchase process type; providing a user interface enabling a user: to select the first seat via the seat map and to initiate a purchase transaction for the first ticket using the first purchase process type, and/or to elect the second seat via the seat map and to initiate a purchase transaction for the second ticket using the second purchase process type.
 39. The system as defined in claim 38, wherein the first purchase process type includes purchase of the first ticket at a preset price and the second purchase process type includes an auction for the second ticket.
 40. The system as defined in claim 38, wherein the first purchase process type includes purchase of the first ticket at a preset price and the second purchase process type includes the user specifying a price at which the user is offering to purchase the second ticket.
 41. The system as defined in claim 38, wherein the seat map indicates via a first color code and/or a first icon that the first ticket for the first seat is available for purchase via the first purchase process type, and wherein the seat map indicates via a second color code and/or a second icon that the second ticket for the second seat is available for purchase via the second purchase process type.
 42. The system as defined in claim 38, further comprising an application programming interface configured to access relationship information of the user from a social network system, wherein the seat map is configured to display an indication as where at least one person, with whom the user has a relationship as determined via the relationship information, will be sitting at the event venue.
 43. The system as defined in claim 38, further comprising an application programming interface configured to access relationship information of the user from a social network system, wherein the seat map is configured to display an indication as which seat at least one person, with whom the user has a relationship as determined via the relationship information, has made an offer to purchase a ticket for.
 44. A method, comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; accessing purchase process information, wherein the purchase process information indicates: a first ticket for a first seat is to be offered for sale via a first purchase process type, and a second ticket for a second seat is to be offered for sale via a second purchase process type different than the first purchase process type; accessing status information regarding a plurality of venue seats, the status information indicating seat availability; transmitting the seat map for display on a user terminal, wherein the seat map indicates seat availability, and where the seat map visually indicates that: the first ticket for the first seat is available for purchase via the first purchase process type, and the second ticket for the second seat is available for purchase via the second purchase process type; providing a user interface enabling a user: to select the first seat via the seat map and to initiate a purchase transaction for the first ticket using the first purchase process type, and/or to elect the second seat via the seat map and to initiate a purchase transaction for the second ticket using the second purchase process type.
 45. A system for providing a seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; transmitting the seat map for display on a terminal of a first user, wherein the seat map indicates seat availability, and providing a user interface enabling the first user: to select the first seat via the seat map and to submit a first offer to purchase a corresponding first ticket for the first seat; identify a second user; condition the offer to purchase the first ticket for the first seat on an acceptance of a second offer from the second user to purchase a second ticket for a second seat; determining if the second offer to purchase the second ticket for the second seat is acceptable; determining if the first offer to purchase the first ticket for the first seat is acceptable, at least partly in response to determining that the first offer to purchase the first ticket for the first seat the second offer to purchase the second ticket for the second seat are acceptable, enabling the purchase of the first ticket to be completed.
 46. The system as defined in claim 45, further comprising an application programming interface configured to access relationship information of the first user from a social network system, wherein the relationship information indicates that the first user and the second user have a relationship, and the seat map is configured to identify the second seat in association with an indication that the second user has made an offer to purchase the second ticket for the second seat.
 47. The system as defined in claim 45, further comprising an application programming interface configured to access relationship information of the user from a social network system, wherein the seat map is configured to display an indication as which seat at least one person, with whom the user has a relationship as determined via the relationship information, has made an offer to purchase a ticket for.
 48. The system as defined in claim 45, wherein behavior of the seat map is dynamically controlled at least in part by a scripting language passed by the system to the seat map.
 49. A method, comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of seats; transmitting the seat map for display on a terminal of a first user, wherein the seat map indicates seat availability, and providing a user interface enabling the first user: to select the first seat via the seat map and to submit a first offer to purchase a corresponding first ticket for the first seat; identify a second user; condition the offer to purchase the first ticket for the first seat on an acceptance of a second offer by the second user to purchase a second ticket for a second seat; determining if the second offer to purchase the second ticket for the second seat is acceptable; determining if the first offer to purchase the first ticket for the first seat is acceptable, at least partly in response to determining that the first offer to purchase the first ticket for the first seat the second offer to purchase the second ticket for the second seat are acceptable, enabling the purchase of the first ticket to be completed.
 50. A system for providing a seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: determining if user activity by a plurality of users is interfering with providing, to a plurality of user terminals, substantially real-time updates to an interactive seat map, wherein the interactive seat map enables a given user to select a specific seat via the interactive seat map and to purchase a seat ticket for the user selected seat; at least partly in response to determining that user activity is interfering with providing, to the plurality of user terminals, substantially real-time updates to the interactive seat map: preventing at least a portion of the plurality of users from using the interactive seat map to purchase user selected seats; and enabling one or more users to purchase seat tickets via a first user interface wherein the user cannot select specific seat to purchase tickets for.
 51. The system as defined in claim 50, wherein the first user interface enables the user to specify a seat price, and the system selects a seat corresponding to the user specified seat price, and enables the user to purchase a ticket for the system selected seat.
 52. The system as defined in claim 50, wherein determining if user activity is interfering with providing, to the plurality of user terminals, substantially real-time updates to the interactive seat map, further comprises determining if changes in seat status information, indicating whether a given seat is available or unavailable, cannot be reflected in the interactive seat map in substantially real time.
 53. A method, comprising: determining if user activity by a plurality of users is interfering with providing, to a plurality of user terminals, substantially real-time updates to an interactive seat map, wherein the interactive seat map enables a given user to select a specific seat via the interactive seat map and to purchase a seat ticket for the user selected seat; at least partly in response to determining that user activity is interfering with providing, to the plurality of user terminals, substantially real-time updates to the interactive seat map: preventing at least a portion of the plurality of users from using the interactive seat map to purchase user selected seats; and enabling one or more users to purchase seat tickets via a first user interface wherein the user cannot select specific seat to purchase tickets for. 54-118. (canceled)
 119. The method as defined in claim 53, wherein the first user interface enables the user to specify a seat price, and the system selects a seat corresponding to the user specified seat price, and enables the user to purchase a ticket for the system selected seat.
 120. The method as defined in claim 53, wherein determining if user activity is interfering with providing, to the plurality of user terminals, substantially real-time updates to the interactive seat map, further comprises determining if changes in seat status information, indicating whether a given seat is available or unavailable, cannot be reflected in the interactive seat map in substantially real time.
 121. A system for providing an interactive seat map, comprising: computing hardware; a non-transitory medium storing instructions that when executed by the computing hardware, cause the computing hardware to perform operations comprising: accessing a seat map for a venue, the seat map including a definition of a plurality of sections and seats within the plurality of sections; accessing pricing information associated with the plurality of venue sections and/or venue seats for a first event; accessing status information regarding a plurality of venue seats, the status information indicating seat availability; transmitting the map for display as an interactive seat map on a user terminal, wherein the interactive map indicates seat availability; providing a user interface via which: a user may select a seat, and submit an offer, including a user specified price, to purchase the ticket for the selected seat from the ticket holder; if the user submits an offer to the ticket holder, transmitting the offer to the ticket holder, and processing an acceptance or refusal of the offer from the ticket holder. 